4.18.15-stable review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.18.15-stable review
This is the start of the stable review cycle for the 4.18.15 release. There are 135 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 Thu Oct 18 17:04:43 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.15-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.18.15-rc1
Edgar Cherkasov <[email protected]>
i2c: i2c-scmi: fix for i2c_smbus_write_block_data
Jan Kara <[email protected]>
mm: Preserve _PAGE_DEVMAP across mprotect() calls
Dan Williams <[email protected]>
filesystem-dax: Fix dax_layout_busy_page() livelock
Jérôme Glisse <[email protected]>
mm/thp: fix call to mmu_notifier in set_pmd_migration_entry() v2
Jann Horn <[email protected]>
mm/mmap.c: don't clobber partially overlapping VMA with MAP_FIXED_NOREPLACE
Will Deacon <[email protected]>
arm64: perf: Reject stand-alone CHAIN events for PMUv3
Marco Felsch <[email protected]>
pinctrl: mcp23s08: fix irq and irqchip setup order
Chris Boot <[email protected]>
mmc: block: avoid multiblock reads for the last sector in SPI mode
Lyude Paul <[email protected]>
drm/nouveau/drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
Ramses Ramírez <[email protected]>
Input: xpad - add support for Xbox1 PDP Camo series gamepad
Tejun Heo <[email protected]>
cgroup: Fix dom_cgrp propagation when enabling threaded mode
Damien Le Moal <[email protected]>
dm linear: fix linear_end_io conditional definition
Mike Snitzer <[email protected]>
dm linear: eliminate linear_end_io call if CONFIG_DM_ZONED disabled
Damien Le Moal <[email protected]>
dm: fix report zone remapping to account for partition offset
Shenghui Wang <[email protected]>
dm cache: destroy migration_cache if cache target registration failed
Eric Farman <[email protected]>
s390/cio: Fix how vfio-ccw checks pinned pages
Adrian Hunter <[email protected]>
perf script python: Fix export-to-sqlite.py sample columns
Adrian Hunter <[email protected]>
perf script python: Fix export-to-postgresql.py occasional failure
Mike Rapoport <[email protected]>
percpu: stop leaking bitmap metadata blocks
Steven Rostedt (VMware) <[email protected]>
vsprintf: Fix off-by-one bug in bstr_printf() processing dereferenced pointers
Mikulas Patocka <[email protected]>
mach64: detect the dot clock divider correctly on sparc
Paul Burton <[email protected]>
MIPS: VDSO: Always map near top of user memory
Paul Burton <[email protected]>
MIPS: Fix CONFIG_CMDLINE handling
David Howells <[email protected]>
afs: Fix clearance of reply
David Howells <[email protected]>
afs: Fix afs_server struct leak
Jann Horn <[email protected]>
mm/vmstat.c: fix outdated vmstat_text
Roman Gushchin <[email protected]>
mm: slowly shrink slabs with a relatively small number of objects
Yong Zhao <[email protected]>
drm/amdkfd: Fix ATS capablity was not reported correctly on some APUs
Yong Zhao <[email protected]>
drm/amdkfd: Change the control stack MTYPE from UC to NC on GFX9
Amber Lin <[email protected]>
drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
Vitaly Kuznetsov <[email protected]>
x86/kvm/lapic: always disable MMIO interface in x2APIC mode
Simon Detheridge <[email protected]>
pinctrl: cannonlake: Fix gpio base for GPP-E
Hans de Goede <[email protected]>
clk: x86: Stop marking clocks as CLK_IS_CRITICAL
Hans de Goede <[email protected]>
clk: x86: add "ether_clk" alias for Bay Trail / Cherry Trail
Stephen Hemminger <[email protected]>
hv_netvsc: pair VF based on serial number
Stephen Hemminger <[email protected]>
PCI: hv: support reporting serial number as slot information
Nicolas Ferre <[email protected]>
ARM: dts: at91: add new compatibility string for macb on sama5d3
Nicolas Ferre <[email protected]>
net: macb: disable scatter-gather for macb on sama5d3
Corentin Labbe <[email protected]>
net: ethernet: ti: add missing GENERIC_ALLOCATOR dependency
Guenter Roeck <[email protected]>
hwmon: (nct6775) Use different register to get fan RPM for fan7
Jongsung Kim <[email protected]>
stmmac: fix valid numbers of unicast filter entries
Guenter Roeck <[email protected]>
hwmon: (nct6775) Fix RPM output for fan7 on NCT6796D
Guenter Roeck <[email protected]>
hwmon: (nct6775) Fix virtual temperature sources for NCT6796D
Tushar Dave <[email protected]>
bpf: use __GFP_COMP while allocating page
Martin KaFai Lau <[email protected]>
bpf: btf: Fix end boundary calculation for type section
Yu Zhao <[email protected]>
sound: don't call skl_init_chip() to reset intel skl soc
Yu Zhao <[email protected]>
sound: enable interrupt after dma buffer initialization
Dan Carpenter <[email protected]>
scsi: qla2xxx: Fix an endian bug in fcpcmd_is_corrupted()
Laura Abbott <[email protected]>
scsi: iscsi: target: Don't use stack buffer for scatterlist
Nicholas Piggin <[email protected]>
KVM: PPC: Book3S HV: Don't use compound_order to determine host mapping size
Tony Lindgren <[email protected]>
mfd: omap-usb-host: Fix dts probe of children
Hermes Zhang <[email protected]>
Bluetooth: hci_ldisc: Free rw_semaphore on close
Matias Karhumaa <[email protected]>
Bluetooth: Use correct tfm to generate OOB data
Johan Hedberg <[email protected]>
Bluetooth: SMP: Fix trying to use non-existent local OOB data
zhong jiang <[email protected]>
drm/pl111: Make sure of_device_id tables are NULL terminated
Akshu Agrawal <[email protected]>
ASoC: AMD: Ensure reset bit is cleared before configuring
Jay Kamat <[email protected]>
Add tests for memory.oom.group
Jay Kamat <[email protected]>
Fix cg_read_strcmp()
Guenter Roeck <[email protected]>
hwmon: (nct6775) Fix access to fan pulse registers
Kuninori Morimoto <[email protected]>
ASoC: rsnd: don't fallback to PIO mode when -EPROBE_DEFER
Kuninori Morimoto <[email protected]>
ASoC: rsnd: adg: care clock-frequency size
Lei Yang <[email protected]>
selftests: memory-hotplug: add required configs
Lei Yang <[email protected]>
selftests/efivarfs: add required kernel configs
Anders Roxell <[email protected]>
selftests: add headers_install to lib.mk
Srinivas Kandagatla <[email protected]>
ASoC: q6routing: initialize data correctly
Danny Smith <[email protected]>
ASoC: sigmadsp: safeload should not have lower byte limit
Pierre-Louis Bossart <[email protected]>
ASoC: wm8804: Add ACPI support
Ryan Lee <[email protected]>
ASoC: max98373: Added 10ms sleep after amp software reset
Thiago Jung Bauermann <[email protected]>
selftests: kselftest: Remove outdated comment
Anders Roxell <[email protected]>
selftests: android: move config up a level
Oder Chiou <[email protected]>
ASoC: rt5514: Fix the issue of the delay volume applied again
Ryan Lee <[email protected]>
ASoC: max98373: Added speaker FS gain cotnrol register to volatile.
Charles Keepax <[email protected]>
ASoC: dapm: Fix NULL pointer deference on CODEC to CODEC DAIs
Hangbin Liu <[email protected]>
vxlan: fill ttl inherit info
Maciej S. Szmigiero <[email protected]>
r8169: set RX_MULTI_EN bit in RxConfig for 8168F-family chips
Heiner Kallweit <[email protected]>
r8169: fix network stalls due to missing bit TXCFG_AUTO_FIFO
Sudarsana Reddy Kalluru <[email protected]>
qed: Fix shmem structure inconsistency between driver and the mfw.
Antoine Tenart <[email protected]>
net: mscc: fix the frame extraction into the skb
Mike Rapoport <[email protected]>
net/ipv6: stop leaking percpu memory in fib6 info
David Ahern <[email protected]>
net/ipv6: Remove extra call to ip6_convert_metrics for multipath case
Vasundhara Volam <[email protected]>
bnxt_en: get the reduced max_irqs by the ones used by RDMA
Vasundhara Volam <[email protected]>
bnxt_en: Fix enables field in HWRM_QUEUE_COS2BW_CFG request
Alaa Hleihel <[email protected]>
net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ
Sabrina Dubroca <[email protected]>
net: ipv4: don't let PMTU updates increase route MTU
Michael Chan <[email protected]>
bnxt_en: Fix VNIC reservations on the PF.
David Ahern <[email protected]>
rtnetlink: Fail dump if target netnsid is invalid
Florian Fainelli <[email protected]>
net: dsa: b53: Keep CPU port as tagged in all VLANs
Eric Dumazet <[email protected]>
inet: make sure to grab rcu_read_lock before using ireq->ireq_opt
Eric Dumazet <[email protected]>
tcp/dccp: fix lockdep issue when SYN is backlogged
Russell King <[email protected]>
sfp: fix oops with ethtool -m
Baruch Siach <[email protected]>
net: phy: phylink: fix SFP interface autodetection
Maciej Żenczykowski <[email protected]>
net-ethtool: ETHTOOL_GUFO did not and should not require CAP_NET_ADMIN
Davide Caratti <[email protected]>
bnxt_en: don't try to offload VLAN 'modify' action
Jakub Kicinski <[email protected]>
nfp: avoid soft lockups under control message storm
Jose Abreu <[email protected]>
net: stmmac: Rework coalesce timer and fix multi-queue races
Mahesh Bandewar <[email protected]>
bonding: fix warning message
Mahesh Bandewar <[email protected]>
bonding: pass link-local packets to bonding master also.
Eran Ben Elisha <[email protected]>
net/mlx5: E-Switch, Fix out of bound access when setting vport rate
Friedemann Gerold <[email protected]>
net: aquantia: memory corruption on jumbo frames
Jianbo Liu <[email protected]>
net/mlx5e: Set vlan masks for all offloaded TC rules
Florian Fainelli <[email protected]>
net: dsa: bcm_sf2: Fix unbind ordering
Jianfeng Tan <[email protected]>
net/packet: fix packet drop as of virtio gso
Jose Abreu <[email protected]>
net: stmmac: Fixup the tail addr setting in xmit path
Eric Dumazet <[email protected]>
tun: napi flags belong to tfile
Eric Dumazet <[email protected]>
tun: initialize napi_mutex unconditionally
Eric Dumazet <[email protected]>
tun: remove unused parameters
Subash Abhinov Kasiviswanathan <[email protected]>
net: qualcomm: rmnet: Fix incorrect allocation flag in receive path
Subash Abhinov Kasiviswanathan <[email protected]>
net: qualcomm: rmnet: Fix incorrect allocation flag in transmit
Sean Tranchetti <[email protected]>
net: qualcomm: rmnet: Skip processing loopback packets
Jiri Kosina <[email protected]>
udp: Unbreak modules that rely on external __skb_recv_udp() availability
Parthasarathy Bhuvaragan <[email protected]>
tipc: fix flow control accounting for implicit connect
Ido Schimmel <[email protected]>
team: Forbid enslaving team device to itself
Xin Long <[email protected]>
sctp: update dst pmtu with the correct daddr
Eric Dumazet <[email protected]>
rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096
Mauricio Faria de Oliveira <[email protected]>
rtnetlink: fix rtnl_fdb_dump() for ndmsg header
Giacinto Cifelli <[email protected]>
qmi_wwan: Added support for Gemalto's Cinterion ALASxx WWAN interface
Shahed Shaikh <[email protected]>
qlcnic: fix Tx descriptor corruption on 82xx devices
Yu Zhao <[email protected]>
net/usb: cancel pending work when unbinding smsc75xx
Florian Fainelli <[email protected]>
net: systemport: Fix wake-up interrupt race during resume
Al Viro <[email protected]>
net: sched: cls_u32: fix hnode refcounting
David Ahern <[email protected]>
net: sched: Add policy validation for tc attributes
Antoine Tenart <[email protected]>
net: mvpp2: fix a txq_done race condition
Maxime Chevallier <[email protected]>
net: mvpp2: Extract the correct ethtype from the skb for tx csum offload
Sean Tranchetti <[email protected]>
netlabel: check for IPV4MASK in addrinfo_get
Jeff Barnhill <[email protected]>
net/ipv6: Display all addresses in output of /proc/net/if_inet6
Sabrina Dubroca <[email protected]>
net: ipv4: update fnhe_pmtu when first hop's MTU changes
Yunsheng Lin <[email protected]>
net: hns: fix for unmapping problem when SMMU is on
Florian Fainelli <[email protected]>
net: dsa: bcm_sf2: Call setup during switch resume
Wei Wang <[email protected]>
ipv6: take rcu lock in rawv6_send_hdrinc()
Eric Dumazet <[email protected]>
ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()
Paolo Abeni <[email protected]>
ip_tunnel: be careful when accessing the inner header
Paolo Abeni <[email protected]>
ip6_tunnel: be careful when accessing the inner header
Mahesh Bandewar <[email protected]>
bonding: avoid possible dead-lock
Venkat Duvvuru <[email protected]>
bnxt_en: free hwrm resources, if driver probe fails.
Michael Chan <[email protected]>
bnxt_en: Fix TX timeout during netpoll.
-------------
Diffstat:
Documentation/devicetree/bindings/net/macb.txt | 1 +
Makefile | 18 +-
arch/arm/boot/dts/sama5d3_emac.dtsi | 2 +-
arch/arm64/kernel/perf_event.c | 7 +
arch/mips/include/asm/processor.h | 10 +-
arch/mips/kernel/process.c | 25 +++
arch/mips/kernel/setup.c | 48 +++--
arch/mips/kernel/vdso.c | 18 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 91 ++++----
arch/x86/include/asm/pgtable_types.h | 2 +-
arch/x86/include/uapi/asm/kvm.h | 1 +
arch/x86/kvm/lapic.c | 22 +-
drivers/bluetooth/hci_ldisc.c | 2 +
drivers/clk/x86/clk-pmc-atom.c | 18 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 +-
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 13 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 21 +-
drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +-
drivers/gpu/drm/pl111/pl111_vexpress.c | 3 +-
drivers/hwmon/nct6775.c | 70 ++++--
drivers/i2c/busses/i2c-scmi.c | 1 +
drivers/input/joystick/xpad.c | 3 +
drivers/md/dm-cache-target.c | 5 +-
drivers/md/dm-flakey.c | 2 +
drivers/md/dm-linear.c | 8 +-
drivers/md/dm.c | 27 ++-
drivers/mfd/omap-usb-host.c | 11 +-
drivers/mmc/core/block.c | 10 +
drivers/net/bonding/bond_main.c | 65 +++---
drivers/net/dsa/b53/b53_common.c | 4 +-
drivers/net/dsa/bcm_sf2.c | 14 +-
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 32 +--
drivers/net/ethernet/broadcom/bcmsysport.c | 22 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 27 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 20 +-
drivers/net/ethernet/cadence/macb_main.c | 8 +
drivers/net/ethernet/hisilicon/hns/hnae.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 ++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 3 +
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 2 +-
drivers/net/ethernet/mscc/ocelot_board.c | 12 +-
.../net/ethernet/netronome/nfp/nfp_net_common.c | 17 +-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 8 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 3 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h | 3 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h | 3 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 12 +-
.../net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 7 +-
drivers/net/ethernet/realtek/r8169.c | 24 +--
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +-
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 14 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 238 ++++++++++++---------
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +-
drivers/net/ethernet/ti/Kconfig | 1 +
drivers/net/hyperv/netvsc.c | 3 +
drivers/net/hyperv/netvsc_drv.c | 58 ++---
drivers/net/phy/phylink.c | 48 +++--
drivers/net/phy/sfp-bus.c | 4 +-
drivers/net/team/team.c | 6 +
drivers/net/tun.c | 43 ++--
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/usb/smsc75xx.c | 1 +
drivers/net/vxlan.c | 3 +
drivers/pci/controller/pci-hyperv.c | 37 ++++
drivers/perf/arm_pmu.c | 8 +-
drivers/pinctrl/intel/pinctrl-cannonlake.c | 2 +-
drivers/pinctrl/pinctrl-mcp23s08.c | 13 +-
drivers/s390/cio/vfio_ccw_cp.c | 2 +-
drivers/scsi/qla2xxx/qla_target.h | 4 +-
drivers/target/iscsi/iscsi_target.c | 22 +-
drivers/video/fbdev/aty/atyfb.h | 3 +-
drivers/video/fbdev/aty/atyfb_base.c | 7 +-
drivers/video/fbdev/aty/mach64_ct.c | 10 +-
fs/afs/rxrpc.c | 2 -
fs/dax.c | 13 +-
include/linux/cgroup-defs.h | 1 +
include/linux/netdevice.h | 7 +
include/linux/perf/arm_pmu.h | 1 +
include/linux/stmmac.h | 1 +
include/linux/virtio_net.h | 18 ++
include/net/bonding.h | 7 +-
include/net/inet_sock.h | 6 -
include/net/ip_fib.h | 1 +
include/sound/hdaudio.h | 1 +
include/sound/soc-dapm.h | 1 +
kernel/bpf/btf.c | 2 +-
kernel/cgroup/cgroup.c | 25 ++-
lib/vsprintf.c | 2 +-
mm/huge_memory.c | 6 -
mm/mmap.c | 2 +-
mm/percpu.c | 1 +
mm/vmscan.c | 11 +
mm/vmstat.c | 1 -
net/bluetooth/smp.c | 16 +-
net/core/dev.c | 28 ++-
net/core/ethtool.c | 1 +
net/core/filter.c | 3 +-
net/core/rtnetlink.c | 41 ++--
net/dccp/input.c | 4 +-
net/dccp/ipv4.c | 4 +-
net/ipv4/fib_frontend.c | 12 +-
net/ipv4/fib_semantics.c | 50 +++++
net/ipv4/inet_connection_sock.c | 5 +-
net/ipv4/ip_sockglue.c | 3 +-
net/ipv4/ip_tunnel.c | 9 +
net/ipv4/route.c | 7 +-
net/ipv4/tcp_input.c | 4 +-
net/ipv4/tcp_ipv4.c | 4 +-
net/ipv4/udp.c | 2 +-
net/ipv6/addrconf.c | 4 +-
net/ipv6/ip6_fib.c | 2 +
net/ipv6/ip6_tunnel.c | 13 +-
net/ipv6/raw.c | 29 ++-
net/ipv6/route.c | 5 -
net/netlabel/netlabel_unlabeled.c | 3 +-
net/packet/af_packet.c | 11 +-
net/sched/cls_u32.c | 10 +-
net/sched/sch_api.c | 24 ++-
net/sctp/transport.c | 12 +-
net/tipc/socket.c | 4 +-
scripts/subarch.include | 13 ++
sound/hda/hdac_controller.c | 15 +-
sound/soc/amd/acp-pcm-dma.c | 21 ++
sound/soc/codecs/max98373.c | 3 +
sound/soc/codecs/rt5514.c | 8 +-
sound/soc/codecs/sigmadsp.c | 3 +-
sound/soc/codecs/wm8804-i2c.c | 15 +-
sound/soc/intel/skylake/skl.c | 2 +-
sound/soc/qcom/qdsp6/q6routing.c | 4 +-
sound/soc/sh/rcar/adg.c | 5 +
sound/soc/sh/rcar/core.c | 10 +-
sound/soc/sh/rcar/dma.c | 4 +
sound/soc/soc-core.c | 4 +-
sound/soc/soc-dapm.c | 4 +
tools/perf/scripts/python/export-to-postgresql.py | 9 +
tools/perf/scripts/python/export-to-sqlite.py | 6 +-
tools/testing/selftests/android/Makefile | 2 +-
tools/testing/selftests/android/{ion => }/config | 0
tools/testing/selftests/android/ion/Makefile | 2 +
tools/testing/selftests/cgroup/cgroup_util.c | 38 +++-
tools/testing/selftests/cgroup/cgroup_util.h | 1 +
tools/testing/selftests/cgroup/test_memcontrol.c | 205 ++++++++++++++++++
tools/testing/selftests/efivarfs/config | 1 +
tools/testing/selftests/futex/functional/Makefile | 1 +
tools/testing/selftests/gpio/Makefile | 7 +-
tools/testing/selftests/kselftest.h | 1 -
tools/testing/selftests/kvm/Makefile | 7 +-
tools/testing/selftests/lib.mk | 12 ++
tools/testing/selftests/memory-hotplug/config | 1 +
tools/testing/selftests/net/Makefile | 1 +
.../selftests/networking/timestamping/Makefile | 1 +
tools/testing/selftests/vm/Makefile | 4 -
163 files changed, 1543 insertions(+), 647 deletions(-)Greg Kroah-Hartman
maintainerPATCH 6/135 ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 64199fc0a46ba211362472f7f942f900af9492fd ]
Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy, do not do it.
--- net/ipv4/ip_sockglue.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
net/ipv4/ip_sockglue.c +1 -2
@@ -149,7 +149,6 @@ static void ip_cmsg_recv_security(structstatic void ip_cmsg_recv_dstaddr (struct msghdr *msg,struct sk_buff *skb) {struct sockaddr_in sin; -const struct iphdr *iph =ip_hdr (skb);__be16 *ports;int end;
@@ -164,7 +163,7 @@ static void ip_cmsg_recv_dstaddr(struct ports = (__be16 *)skb_transport_header (skb); sin.sin_family =AF_INET ; - sin.sin_addr.s_addr = iph->daddr; + sin.sin_addr.s_addr =ip_hdr (skb)->daddr; sin.sin_port = ports[1 ];memset (sin.sin_zero,0 ,sizeof (sin.sin_zero));
Greg Kroah-Hartman
maintainerPATCH 8/135 net: dsa: bcm_sf2: Call setup during switch resume
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit 54baca096386d862d19c10f58f34bf787c6b3cbe ]
There is no reason to open code what the switch setup function does, in fact, because we just issued a switch reset, we would make all the register get their default values, including for instance, having unused port be enabled again and wasting power and leading to an inappropriate switch core clock being selected.
--- drivers/net/dsa/bcm_sf2.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
drivers/net/dsa/bcm_sf2.c +1 -9
@@ -698,7 +698,6 @@ static int bcm_sf2_sw_suspend(struct dsastatic int bcm_sf2_sw_resume (struct dsa_switch *ds) {struct bcm_sf2_priv *priv =bcm_sf2_to_priv (ds); -unsigned int port;int ret; ret =bcm_sf2_sw_rst (priv);
@@ -710,14 +709,7 @@ static int bcm_sf2_sw_resume(struct dsa_if (priv->hw_params.num_gphy ==1 )bcm_sf2_gphy_enable_set (ds, true); -for (port =0 ; port <DSA_MAX_PORTS ; port++) { -if (dsa_is_user_port (ds, port)) -bcm_sf2_port_setup (ds, port,NULL ); -else if (dsa_is_cpu_port (ds, port)) -bcm_sf2_imp_setup (ds, port); - } - -bcm_sf2_enable_acb (ds); + ds->ops->setup (ds);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 12/135 netlabel: check for IPV4MASK in addrinfo_get
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Tranchetti <[email protected]>
[ Upstream commit f88b4c01b97e09535505cf3c327fdbce55c27f00 ]
netlbl_unlabel_addrinfo_get() assumes that if it finds the NLBL_UNLABEL_A_IPV4ADDR attribute, it must also have the NLBL_UNLABEL_A_IPV4MASK attribute as well. However, this is not necessarily the case as the current checks in netlbl_unlabel_staticadd() and friends are not sufficent to enforce this.
If passed a netlink message with NLBL_UNLABEL_A_IPV4ADDR, NLBL_UNLABEL_A_IPV6ADDR, and NLBL_UNLABEL_A_IPV6MASK attributes, these functions will all call netlbl_unlabel_addrinfo_get() which will then attempt dereference NULL when fetching the non-existent NLBL_UNLABEL_A_IPV4MASK attribute:
Unable to handle kernel NULL pointer dereference at virtual address 0 Process unlab (pid: 31762, stack limit = 0xffffff80502d8000) Call trace: netlbl_unlabel_addrinfo_get+0x44/0xd8 netlbl_unlabel_staticremovedef+0x98/0xe0 genl_rcv_msg+0x354/0x388 netlink_rcv_skb+0xac/0x118 genl_rcv+0x34/0x48 netlink_unicast+0x158/0x1f0 netlink_sendmsg+0x32c/0x338 sock_sendmsg+0x44/0x60 ___sys_sendmsg+0x1d0/0x2a8 __sys_sendmsg+0x64/0xb4 SyS_sendmsg+0x34/0x4c el0_svc_naked+0x34/0x38 Code: 51001149 7100113f 540000a0 f9401508 (79400108) ---[ end trace f6438a488e737143 ]--- Kernel panic - not syncing: Fatal exception
--- net/netlabel/netlabel_unlabeled.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/netlabel/netlabel_unlabeled.c +2 -1
@@ -781,7 +781,8 @@ static int netlbl_unlabel_addrinfo_get(s {u32 addr_len; -if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR ]) { +if (info->attrs[NLBL_UNLABEL_A_IPV4ADDR ] && + info->attrs[NLBL_UNLABEL_A_IPV4MASK ]) { addr_len =nla_len (info->attrs[NLBL_UNLABEL_A_IPV4ADDR ]);if (addr_len !=sizeof (struct in_addr ) && addr_len !=nla_len (info->attrs[NLBL_UNLABEL_A_IPV4MASK ]))
Greg Kroah-Hartman
maintainerPATCH 13/135 net: mvpp2: Extract the correct ethtype from the skb for tx csum offload
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maxime Chevallier <[email protected]>
[ Upstream commit 35f3625c21852ad839f20c91c7d81c4c1101e207 ]
When offloading the L3 and L4 csum computation on TX, we need to extract the l3_proto from the ethtype, independently of the presence of a vlan tag.
The actual driver uses skb->protocol as-is, resulting in packets with the wrong L4 checksum being sent when there's a vlan tag in the packet header and checksum offloading is enabled.
This commit makes use of vlan_protocol_get() to get the correct ethtype regardless the presence of a vlan tag.
--- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +5 -4
@@ -1725,7 +1725,7 @@ static void mvpp2_txq_desc_put(struct mv }/* Set Tx descriptors fields relevant for CSUM calculation */ -static u32 mvpp2_txq_desc_csum (int l3_offs,int l3_proto, +static u32 mvpp2_txq_desc_csum (int l3_offs,__be16 l3_proto,int ip_hdr_len,int l4_proto) {u32 command;
@@ -2600,14 +2600,15 @@ static u32 mvpp2_skb_tx_csum(struct mvppif (skb->ip_summed ==CHECKSUM_PARTIAL ) {int ip_hdr_len =0 ;u8 l4_proto; +__be16 l3_proto =vlan_get_protocol (skb); -if (skb->protocol ==htons (ETH_P_IP )) { +if (l3_proto ==htons (ETH_P_IP )) {struct iphdr *ip4h =ip_hdr (skb);/* Calculate IPv4 checksum and L4 checksum */ ip_hdr_len = ip4h->ihl; l4_proto = ip4h->protocol; - }else if (skb->protocol ==htons (ETH_P_IPV6 )) { + }else if (l3_proto ==htons (ETH_P_IPV6 )) {struct ipv6hdr *ip6h =ipv6_hdr (skb);/* Read l4_protocol from one of IPv6 extra headers */
@@ -2619,7 +2620,7 @@ static u32 mvpp2_skb_tx_csum(struct mvpp }return mvpp2_txq_desc_csum (skb_network_offset (skb), - skb->protocol, ip_hdr_len, l4_proto); + l3_proto, ip_hdr_len, l4_proto); }return MVPP2_TXD_L4_CSUM_NOT |MVPP2_TXD_IP_CSUM_DISABLE ;
Greg Kroah-Hartman
maintainerPATCH 17/135 net: systemport: Fix wake-up interrupt race during resume
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit 45ec318578c0c22a11f5b9927d064418e1ab1905 ]
The AON_PM_L2 is normally used to trigger and identify the source of a wake-up event. Since the RX_SYS clock is no longer turned off, we also have an interrupt being sent to the SYSTEMPORT INTRL_2_0 controller, and that interrupt remains active up until the magic packet detector is disabled which happens much later during the driver resumption.
The race happens if we have a CPU that is entering the SYSTEMPORT INTRL2_0 handler during resume, and another CPU has managed to clear the wake-up interrupt during bcm_sysport_resume_from_wol(). In that case, we have the first CPU stuck in the interrupt handler with an interrupt cause that has been cleared under its feet, and so we keep returning IRQ_NONE and we never make any progress.
This was not a problem before because we would always turn off the RX_SYS clock during WoL, so the SYSTEMPORT INTRL2_0 would also be turned off as well, thus not latching the interrupt.
The fix is to make sure we do not enable either the MPD or BRCM_TAG_MATCH interrupts since those are redundant with what the AON_PM_L2 interrupt controller already processes and they would cause such a race to occur.
--- drivers/net/ethernet/broadcom/bcmsysport.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/net/ethernet/broadcom/bcmsysport.c +11 -11
@@ -1045,14 +1045,22 @@ static void bcm_sysport_resume_from_wol( {u32 reg; -/* Stop monitoring MPD interrupt */ -intrl2_0_mask_set (priv,INTRL2_0_MPD ); -/* Clear the MagicPacket detection logic */ reg =umac_readl (priv,UMAC_MPD_CTRL ); reg &= ~MPD_EN ;umac_writel (priv, reg,UMAC_MPD_CTRL ); + reg =intrl2_0_readl (priv,INTRL2_CPU_STATUS ); +if (reg &INTRL2_0_MPD ) +netdev_info (priv->netdev,"Wake-on-LAN (MPD) interrupt!\n" ); + +if (reg &INTRL2_0_BRCM_MATCH_TAG ) { + reg =rxchk_readl (priv,RXCHK_BRCM_TAG_MATCH_STATUS ) & +RXCHK_BRCM_TAG_MATCH_MASK ; +netdev_info (priv->netdev, +"Wake-on-LAN (filters 0x%02x) interrupt!\n" , reg); + } +netif_dbg (priv, wol, priv->netdev,"resumed from WOL\n" ); }
@@ -1102,11 +1110,6 @@ static irqreturn_t bcm_sysport_rx_isr(inif (priv->irq0_stat &INTRL2_0_TX_RING_FULL )bcm_sysport_tx_reclaim_all (priv); -if (priv->irq0_stat &INTRL2_0_MPD ) { -netdev_info (priv->netdev,"Wake-on-LAN interrupt!\n" ); -bcm_sysport_resume_from_wol (priv); - } -if (!priv->is_lite) goto out;
@@ -2459,9 +2462,6 @@ static int bcm_sysport_suspend_to_wol(st/* UniMAC receive needs to be turned on */ umac_enable_set (priv,CMD_RX_EN ,1 ); -/* Enable the interrupt wake-up source */ -intrl2_0_mask_clear (priv,INTRL2_0_MPD ); -netif_dbg (priv, wol, ndev,"entered WOL mode\n" );return 0 ;
Greg Kroah-Hartman
maintainerPATCH 19/135 qlcnic: fix Tx descriptor corruption on 82xx devices
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shahed Shaikh <[email protected]>
[ Upstream commit c333fa0c4f220f8f7ea5acd6b0ebf3bf13fd684d ]
In regular NIC transmission flow, driver always configures MAC using Tx queue zero descriptor as a part of MAC learning flow.
But with multi Tx queue supported NIC, regular transmission can occur on any non-zero Tx queue and from that context it uses
Tx queue zero descriptor to configure MAC, at the same time TX queue zero could be used by another CPU for regular transmission which could lead to Tx queue zero descriptor corruption and cause FW abort.
This patch fixes this in such a way that driver always configures learned MAC address from the same Tx queue which is used for regular transmission.
--- drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 8 +++++--- drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 3 ++- drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h | 3 ++- drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h | 3 ++- drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 12 ++++++------ 5 files changed, 17 insertions(+), 12 deletions(-)
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h +5 -3
@@ -1800,7 +1800,8 @@ struct qlcnic_hardware_ops {int (*config_loopback) (struct qlcnic_adapter *,u8 );int (*clear_loopback) (struct qlcnic_adapter *,u8 );int (*config_promisc_mode) (struct qlcnic_adapter *,u32 ); -void (*change_l2_filter) (struct qlcnic_adapter *,u64 *,u16 ); +void (*change_l2_filter)(struct qlcnic_adapter *adapter,u64 *addr, +u16 vlan,struct qlcnic_host_tx_ring *tx_ring);int (*get_board_info) (struct qlcnic_adapter *);void (*set_mac_filter_count) (struct qlcnic_adapter *);void (*free_mac_list) (struct qlcnic_adapter *);
@@ -2064,9 +2065,10 @@ static inline int qlcnic_nic_set_promisc }static inline void qlcnic_change_filter (struct qlcnic_adapter *adapter, -u64 *addr,u16 id) +u64 *addr,u16 vlan, +struct qlcnic_host_tx_ring *tx_ring) { - adapter->ahw->hw_ops->change_l2_filter (adapter, addr, id); + adapter->ahw->hw_ops->change_l2_filter (adapter, addr, vlan, tx_ring); }static inline int qlcnic_get_board_info (struct qlcnic_adapter *adapter)
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c +2 -1
@@ -2135,7 +2135,8 @@ out: }void qlcnic_83xx_change_l2_filter (struct qlcnic_adapter *adapter,u64 *addr, -u16 vlan_id) +u16 vlan_id, +struct qlcnic_host_tx_ring *tx_ring) {u8 mac[ETH_ALEN ];memcpy (&mac, addr,ETH_ALEN );
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h +2 -1
@@ -550,7 +550,8 @@ int qlcnic_83xx_wrt_reg_indirect(structint qlcnic_83xx_nic_set_promisc (struct qlcnic_adapter *,u32 );int qlcnic_83xx_config_hw_lro (struct qlcnic_adapter *,int );int qlcnic_83xx_config_rss (struct qlcnic_adapter *,int ); -void qlcnic_83xx_change_l2_filter (struct qlcnic_adapter *,u64 *,u16 ); +void qlcnic_83xx_change_l2_filter (struct qlcnic_adapter *adapter,u64 *addr, +u16 vlan,struct qlcnic_host_tx_ring *ring);int qlcnic_83xx_get_pci_info (struct qlcnic_adapter *,struct qlcnic_pci_info *);int qlcnic_83xx_set_nic_info (struct qlcnic_adapter *,struct qlcnic_info *);void qlcnic_83xx_initialize_nic (struct qlcnic_adapter *,int );
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h +2 -1
@@ -173,7 +173,8 @@ int qlcnic_82xx_napi_add(struct qlcnic_a struct net_device *netdev);void qlcnic_82xx_get_beacon_state (struct qlcnic_adapter *);void qlcnic_82xx_change_filter (struct qlcnic_adapter *adapter, -u64 *uaddr,u16 vlan_id); +u64 *uaddr,u16 vlan_id, +struct qlcnic_host_tx_ring *tx_ring);int qlcnic_82xx_config_intr_coalesce (struct qlcnic_adapter *,struct ethtool_coalesce *);int qlcnic_82xx_set_rx_coalesce (struct qlcnic_adapter *);
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c +6 -6
@@ -268,13 +268,12 @@ static void qlcnic_add_lb_filter(struct }void qlcnic_82xx_change_filter (struct qlcnic_adapter *adapter,u64 *uaddr, -u16 vlan_id) +u16 vlan_id,struct qlcnic_host_tx_ring *tx_ring) {struct cmd_desc_type0 *hwdesc;struct qlcnic_nic_req *req;struct qlcnic_mac_req *mac_req;struct qlcnic_vlan_req *vlan_req; -struct qlcnic_host_tx_ring *tx_ring = adapter->tx_ring;u32 producer;u64 word;
@@ -301,7 +300,8 @@ void qlcnic_82xx_change_filter(struct qlstatic void qlcnic_send_filter (struct qlcnic_adapter *adapter,struct cmd_desc_type0 *first_desc, -struct sk_buff *skb) +struct sk_buff *skb, +struct qlcnic_host_tx_ring *tx_ring) {struct vlan_ethhdr *vh = (struct vlan_ethhdr *)(skb->data);struct ethhdr *phdr = (struct ethhdr *)(skb->data);
@@ -335,7 +335,7 @@ static void qlcnic_send_filter(struct ql tmp_fil->vlan_id == vlan_id) {if (jiffies > (QLCNIC_READD_AGE *HZ + tmp_fil->ftime))qlcnic_change_filter (adapter, &src_addr, - vlan_id); + vlan_id, tx_ring); tmp_fil->ftime = jiffies;return ; }
@@ -350,7 +350,7 @@ static void qlcnic_send_filter(struct qlif (!fil)return ; -qlcnic_change_filter (adapter, &src_addr, vlan_id); +qlcnic_change_filter (adapter, &src_addr, vlan_id, tx_ring); fil->ftime = jiffies; fil->vlan_id = vlan_id;memcpy (fil->faddr, &src_addr,ETH_ALEN );
@@ -766,7 +766,7 @@ netdev_tx_t qlcnic_xmit_frame(struct sk_ }if (adapter->drv_mac_learn) -qlcnic_send_filter (adapter, first_desc, skb); +qlcnic_send_filter (adapter, first_desc, skb, tx_ring); tx_ring->tx_stats.tx_bytes += skb->len; tx_ring->tx_stats.xmit_called++;
Greg Kroah-Hartman
maintainerPATCH 20/135 qmi_wwan: Added support for Gemaltos Cinterion ALASxx WWAN interface
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Giacinto Cifelli <[email protected]>
[ Upstream commit 4f7617705bfff84d756fe4401a1f4f032f374984 ]
Added support for Gemalto's Cinterion ALASxx WWAN interfaces by adding QMI_FIXED_INTF with Cinterion's VID and PID.
--- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/usb/qmi_wwan.c +1 -0
@@ -1234,6 +1234,7 @@ static const struct usb_device_id produc {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */ {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */ {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */ + {QMI_FIXED_INTF(0x1e2d, 0x0063, 10)}, /* Cinterion ALASxx (1 RmNet) */ {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */ {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */ {QMI_FIXED_INTF(0x1e2d, 0x0083, 4)}, /* Cinterion PHxx,PXxx (1 RmNet + USB Audio)*/
Greg Kroah-Hartman
maintainerPATCH 22/135 rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 0e1d6eca5113858ed2caea61a5adc03c595f6096 ]
We have an impressive number of syzkaller bugs that are linked to the fact that syzbot was able to create a networking device with millions of TX (or RX) queues.
Let's limit the number of RX/TX queues to 4096, this really should cover all known cases.
A separate patch will add various cond_resched() in the loops handling sysfs entries at device creation and dismantle.
Tested:
lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap RTNETLINK answers: Invalid argument
lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap
real 0m0.180s
user 0m0.000s
sys 0m0.107s
--- net/core/rtnetlink.c | 6 ++++++ 1 file changed, 6 insertions(+)
net/core/rtnetlink.c +6 -0
@@ -2787,6 +2787,12 @@ struct net_device *rtnl_create_link(struelse if (ops->get_num_rx_queues) num_rx_queues = ops->get_num_rx_queues (); +if (num_tx_queues <1 || num_tx_queues >4096 ) +return ERR_PTR (-EINVAL ); + +if (num_rx_queues <1 || num_rx_queues >4096 ) +return ERR_PTR (-EINVAL ); + dev =alloc_netdev_mqs (ops->priv_size, ifname, name_assign_type, ops->setup, num_tx_queues, num_rx_queues);if (!dev)
Greg Kroah-Hartman
maintainerPATCH 36/135 net/mlx5e: Set vlan masks for all offloaded TC rules
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jianbo Liu <[email protected]>
[ Upstream commit cee26487620bc9bc3c7db21b6984d91f7bae12ae ]
In flow steering, if asked to, the hardware matches on the first ethertype which is not vlan. It's possible to set a rule as follows, which is meant to match on untagged packet, but will match on a vlan packet:
tc filter add dev eth0 parent ffff: protocol ip flower ...
To avoid this for packets with single tag, we set vlan masks to tell hardware to check the tags for every matched packet.
--- drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c +3 -0
@@ -1339,6 +1339,9 @@ static int __parse_cls_flower(struct mlx *match_level =MLX5_MATCH_L2 ; } + }else { +MLX5_SET (fte_match_set_lyr_2_4, headers_c, svlan_tag,1 ); +MLX5_SET (fte_match_set_lyr_2_4, headers_c, cvlan_tag,1 ); }if (dissector_uses_key (f->dissector,FLOW_DISSECTOR_KEY_BASIC )) {
Greg Kroah-Hartman
maintainerPATCH 38/135 net/mlx5: E-Switch, Fix out of bound access when setting vport rate
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eran Ben Elisha <[email protected]>
[ Upstream commit 11aa5800ed66ed0415b7509f02881c76417d212a ]
The code that deals with eswitch vport bw guarantee was going beyond the eswitch vport array limit, fix that. This was pointed out by the kernel address sanitizer (KASAN).
The error from KASAN log:
[2018-09-15 15:04:45] BUG: KASAN: slab-out-of-bounds in mlx5_eswitch_set_vport_rate+0x8c1/0xae0 [mlx5_core]
--- drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c +2 -2
@@ -2000,7 +2000,7 @@ static u32 calculate_vports_min_rate_divu32 max_guarantee =0 ;int i; -for (i =0 ; i <= esw->total_vports; i++) { +for (i =0 ; i < esw->total_vports; i++) { evport = &esw->vports[i];if (!evport->enabled || evport->info.min_rate < max_guarantee)continue ;
@@ -2020,7 +2020,7 @@ static int normalize_vports_min_rate(strint err;int i; -for (i =0 ; i <= esw->total_vports; i++) { +for (i =0 ; i < esw->total_vports; i++) { evport = &esw->vports[i];if (!evport->enabled)continue ;
Greg Kroah-Hartman
maintainerPATCH 42/135 nfp: avoid soft lockups under control message storm
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit ff58e2df62ce29d0552278c290ae494b30fe0c6f ]
When FW floods the driver with control messages try to exit the cmsg processing loop every now and then to avoid soft lockups. Cmsg processing is generally very lightweight so 512 seems like a reasonable budget, which should not be exceeded under normal conditions.
--- drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/net/ethernet/netronome/nfp/nfp_net_common.c +12 -5
@@ -2068,14 +2068,17 @@ nfp_ctrl_rx_one(struct nfp_net *nn, strureturn true; } -static void nfp_ctrl_rx (struct nfp_net_r_vector *r_vec) +static bool nfp_ctrl_rx (struct nfp_net_r_vector *r_vec) {struct nfp_net_rx_ring *rx_ring = r_vec->rx_ring;struct nfp_net *nn = r_vec->nfp_net;struct nfp_net_dp *dp = &nn->dp; +unsigned int budget =512 ; -while (nfp_ctrl_rx_one (nn, dp, r_vec, rx_ring)) +while (nfp_ctrl_rx_one (nn, dp, r_vec, rx_ring) && budget--)continue ; + +return budget; }static void nfp_ctrl_poll (unsigned long arg)
@@ -2087,9 +2090,13 @@ static void nfp_ctrl_poll(unsigned long__nfp_ctrl_tx_queued (r_vec);spin_unlock_bh (&r_vec->lock); -nfp_ctrl_rx (r_vec); - -nfp_net_irq_unmask (r_vec->nfp_net, r_vec->irq_entry); +if (nfp_ctrl_rx (r_vec)) { +nfp_net_irq_unmask (r_vec->nfp_net, r_vec->irq_entry); + }else { +tasklet_schedule (&r_vec->tasklet); +nn_dp_warn (&r_vec->nfp_net->dp, +"control message budget exceeded!\n" ); + } }/* Setup and Configuration
Greg Kroah-Hartman
maintainerPATCH 51/135 bnxt_en: Fix VNIC reservations on the PF.
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Chan <[email protected]>
[ Upstream commit dbe80d446c859873820eedfff4abc61c71f1927b ]
The enables bit for VNIC was set wrong when calling the HWRM_FUNC_CFG firmware call to reserve VNICs. This has the effect that the firmware will keep a large number of VNICs for the PF, and having very few for VFs. DPDK driver running on the VFs, which requires more VNICs, may not work properly as a result.
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +1 -1
@@ -4651,7 +4651,7 @@ __bnxt_hwrm_reserve_pf_rings(struct bnxt FUNC_CFG_REQ_ENABLES_NUM_STAT_CTXS :0 ; enables |= ring_grps ?FUNC_CFG_REQ_ENABLES_NUM_HW_RING_GRPS :0 ; - enables |= vnics ?FUNC_VF_CFG_REQ_ENABLES_NUM_VNICS :0 ; + enables |= vnics ?FUNC_CFG_REQ_ENABLES_NUM_VNICS :0 ; req->num_rx_rings =cpu_to_le16 (rx_rings); req->num_hw_ring_grps =cpu_to_le16 (ring_grps);
Greg Kroah-Hartman
maintainerPATCH 58/135 net: mscc: fix the frame extraction into the skb
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antoine Tenart <[email protected]>
[ Upstream commit 652ef42c134da1bbb03bd4c9b4291dfaf8d7febb ]
When extracting frames from the Ocelot switch, the frame check sequence (FCS) is present at the end of the data extracted. The FCS was put into the sk buffer which introduced some issues (as length related ones), as the FCS shouldn't be part of an Rx sk buffer.
This patch fixes the Ocelot switch extraction behaviour by discarding the FCS.
--- drivers/net/ethernet/mscc/ocelot_board.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/net/ethernet/mscc/ocelot_board.c +9 -3
@@ -91,7 +91,7 @@ static irqreturn_t ocelot_xtr_irq_handlestruct sk_buff *skb;struct net_device *dev;u32 *buf; -int sz, len; +int sz, len, buf_len;u32 ifh[4 ];u32 val;struct frame_info info;
@@ -116,14 +116,20 @@ static irqreturn_t ocelot_xtr_irq_handle err = -ENOMEM ;break ; } - buf = (u32 *)skb_put (skb, info.len); + buf_len = info.len -ETH_FCS_LEN ; + buf = (u32 *)skb_put (skb, buf_len); len =0 ;do { sz =ocelot_rx_frame_word (ocelot, grp, false, &val); *buf++ = val; len += sz; - }while ((sz ==4 ) && (len < info.len)); + }while (len < buf_len); + +/* Read the FCS and discard it */ + sz =ocelot_rx_frame_word (ocelot, grp, false, &val); +/* Update the statistics if part of the FCS was read before */ + len -=ETH_FCS_LEN - sz;if (sz <0 ) { err = sz;
Greg Kroah-Hartman
maintainerPATCH 59/135 qed: Fix shmem structure inconsistency between driver and the mfw.
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sudarsana Reddy Kalluru <[email protected]>
[ Upstream commit 5f672090e44f4951084c5e1d6b0668a5fc422af8 ]
The structure shared between driver and the management FW (mfw) differ in sizes. This would lead to issues when driver try to access the structure members which are not-aligned with the mfw copy e.g., data_ptr usage in the case of mfw_tlv request.
Align the driver structure with mfw copy, add reserved field(s) to driver structure for the members not used by the driver.
--- drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/qlogic/qed/qed_hsi.h +1 -0
@@ -11987,6 +11987,7 @@ struct public_global {u32 running_bundle_id;s32 external_temperature;u32 mdump_reason; +u64 reserved;u32 data_ptr;u32 data_size; };
Greg Kroah-Hartman
maintainerPATCH 62/135 vxlan: fill ttl inherit info
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangbin Liu <[email protected]>
[ Upstream commit 8fd780698745ba121530c5c20fd237aacde4c371 ]
When add vxlan ttl inherit support, I forgot to fill it when dump vlxan info. Fix it now.
--- drivers/net/vxlan.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/vxlan.c +3 -0
@@ -3537,6 +3537,7 @@ static size_t vxlan_get_size(const strucnla_total_size (sizeof (__u32)) +/* IFLA_VXLAN_LINK */ nla_total_size (sizeof (struct in6_addr )) +/* IFLA_VXLAN_LOCAL{6} */ nla_total_size (sizeof (__u8)) +/* IFLA_VXLAN_TTL */ +nla_total_size (sizeof (__u8)) +/* IFLA_VXLAN_TTL_INHERIT */ nla_total_size (sizeof (__u8)) +/* IFLA_VXLAN_TOS */ nla_total_size (sizeof (__be32)) +/* IFLA_VXLAN_LABEL */ nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_LEARNING */
@@ -3601,6 +3602,8 @@ static int vxlan_fill_info(struct sk_buf }if (nla_put_u8 (skb,IFLA_VXLAN_TTL , vxlan->cfg.ttl) || +nla_put_u8 (skb,IFLA_VXLAN_TTL_INHERIT , + !!(vxlan->cfg.flags &VXLAN_F_TTL_INHERIT )) ||nla_put_u8 (skb,IFLA_VXLAN_TOS , vxlan->cfg.tos) ||nla_put_be32 (skb,IFLA_VXLAN_LABEL , vxlan->cfg.label) || nla_put_u8(skb, IFLA_VXLAN_LEARNING,
Greg Kroah-Hartman
maintainerPATCH 73/135 selftests/efivarfs: add required kernel configs
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lei Yang <[email protected]>
[ Upstream commit 53cf59d6c0ad3edc4f4449098706a8f8986258b6 ]
add config file
--- tools/testing/selftests/efivarfs/config | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/testing/selftests/efivarfs/config
tools/testing/selftests/efivarfs/config new file +1 -0
@@ -0,0 +1 @@ +CONFIG_EFIVAR_FS=y
Greg Kroah-Hartman
maintainerPATCH 78/135 Fix cg_read_strcmp()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Kamat <[email protected]>
[ Upstream commit 48c2bb0b9cf863e0ed78e269f188ce65b73e0fd1 ]
Fix a couple issues with cg_read_strcmp(), to improve correctness of cgroup tests
- Fix cg_read_strcmp() always returning 0 for empty "needle" strings. Previously, this function read to a size = 1 buffer when comparing against empty strings, which would lead to cg_read_strcmp() comparing two empty strings.
- Fix a memory leak in cg_read_strcmp()
--- tools/testing/selftests/cgroup/cgroup_util.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
tools/testing/selftests/cgroup/cgroup_util.c +14 -3
@@ -89,17 +89,28 @@ int cg_read(const char *cgroup, const chint cg_read_strcmp (const char *cgroup,const char *control,const char *expected) { -size_t size =strlen (expected) +1 ; +size_t size;char *buf; +int ret; + +/* Handle the case of comparing against empty string */ +if (!expected) + size =32 ; +else + size =strlen (expected) +1 ; buf =malloc (size);if (!buf)return -1 ; -if (cg_read (cgroup, control, buf, size)) +if (cg_read (cgroup, control, buf, size)) { +free (buf);return -1 ; + } -return strcmp (expected, buf); + ret =strcmp (expected, buf); +free (buf); +return ret; }int cg_read_strstr (const char *cgroup,const char *control,const char *needle)
Greg Kroah-Hartman
maintainerPATCH 80/135 ASoC: AMD: Ensure reset bit is cleared before configuring
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akshu Agrawal <[email protected]>
[ Upstream commit 2a665dba016d5493c7d826fec82b0cb643b30d42 ]
HW register descriptions says:
"DMA Channel Reset...Software must confirm that this bit is cleared before reprogramming any of the channel configuration registers." There could be cases where dma stop errored out leaving dma channel in reset state. We need to ensure that before the start of another dma, channel is out of the reset state.
--- sound/soc/amd/acp-pcm-dma.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
sound/soc/amd/acp-pcm-dma.c +21 -0
@@ -16,6 +16,7 @@#include <linux/module.h> #include <linux/delay.h> #include <linux/io.h> +#include <linux/iopoll.h> #include <linux/sizes.h> #include <linux/pm_runtime.h>
@@ -184,6 +185,24 @@ static void config_dma_descriptor_in_sraacp_reg_write (descr_info->xfer_val, acp_mmio, mmACP_SRBM_Targ_Idx_Data); } +static void pre_config_reset (void __iomem *acp_mmio,u16 ch_num) +{ +u32 dma_ctrl; +int ret; + +/* clear the reset bit */ + dma_ctrl =acp_reg_read (acp_mmio, mmACP_DMA_CNTL_0 + ch_num); + dma_ctrl &= ~ACP_DMA_CNTL_0__DMAChRst_MASK; +acp_reg_write (dma_ctrl, acp_mmio, mmACP_DMA_CNTL_0 + ch_num); +/* check the reset bit before programming configuration registers */ + ret =readl_poll_timeout (acp_mmio + ((mmACP_DMA_CNTL_0 + ch_num) *4 ), + dma_ctrl, + !(dma_ctrl & ACP_DMA_CNTL_0__DMAChRst_MASK), +100 ,ACP_DMA_RESET_TIME ); +if (ret <0 ) +pr_err ("Failed to clear reset of channel : %d\n" , ch_num); +} +/* * Initialize the DMA descriptor information for transfer between * system memory <-> ACP SRAM
@@ -238,6 +257,7 @@ static void set_acp_sysmem_dma_descriptoconfig_dma_descriptor_in_sram (acp_mmio, dma_dscr_idx, &dmadscr[i]); } +pre_config_reset (acp_mmio, ch); config_acp_dma_channel(acp_mmio, ch, dma_dscr_idx - 1, NUM_DSCRS_PER_CHANNEL,
@@ -277,6 +297,7 @@ static void set_acp_to_i2s_dma_descriptoconfig_dma_descriptor_in_sram (acp_mmio, dma_dscr_idx, &dmadscr[i]); } +pre_config_reset (acp_mmio, ch);/* Configure the DMA channel with the above descriptore */ config_acp_dma_channel(acp_mmio, ch, dma_dscr_idx - 1, NUM_DSCRS_PER_CHANNEL,
Greg Kroah-Hartman
maintainerPATCH 86/135 KVM: PPC: Book3S HV: Dont use compound_order to determine host mapping size
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit 71d29f43b6332badc5598c656616a62575e83342 ]
THP paths can defer splitting compound pages until after the actual remap and TLB flushes to split a huge PMD/PUD. This causes radix partition scope page table mappings to get out of synch with the host qemu page table mappings.
This results in random memory corruption in the guest when running with THP. The easiest way to reproduce is use KVM balloon to free up a lot of memory in the guest and then shrink the balloon to give the memory back, while some work is being done in the guest.
--- arch/powerpc/kvm/book3s_64_mmu_radix.c | 91 +++++++++++++-------------------- 1 file changed, 37 insertions(+), 54 deletions(-)
arch/powerpc/kvm/book3s_64_mmu_radix.c +37 -54
@@ -538,8 +538,8 @@ int kvmppc_book3s_radix_page_fault(struc unsigned long ea, unsigned long dsisr) {struct kvm *kvm = vcpu->kvm; -unsigned long mmu_seq, pte_size; -unsigned long gpa, gfn, hva, pfn; +unsigned long mmu_seq; +unsigned long gpa, gfn, hva;struct kvm_memory_slot *memslot;struct page *page =NULL ;long ret;
@@ -636,9 +636,10 @@ int kvmppc_book3s_radix_page_fault(struc*/ hva =gfn_to_hva_memslot (memslot, gfn);if (upgrade_p &&__get_user_pages_fast (hva,1 ,1 , &page) =1 ) { - pfn =page_to_pfn (page); upgrade_write = true; }else { +unsigned long pfn; +/* Call KVM generic code to do the slow-path check */ pfn =__gfn_to_pfn_memslot (memslot, gfn, false,NULL , writing, upgrade_p);
@@ -652,63 +653,45 @@ int kvmppc_book3s_radix_page_fault(struc } } -/* See if we can insert a 1GB or 2MB large PTE here */ - level =0 ; -if (page &&PageCompound (page)) { - pte_size =PAGE_SIZE <<compound_order (compound_head (page)); -if (pte_size >=PUD_SIZE && - (gpa & (PUD_SIZE -PAGE_SIZE )) = - (hva & (PUD_SIZE -PAGE_SIZE ))) { - level =2 ; - pfn &= ~((PUD_SIZE >>PAGE_SHIFT ) -1 ); - }else if (pte_size >=PMD_SIZE && - (gpa & (PMD_SIZE -PAGE_SIZE )) = - (hva & (PMD_SIZE -PAGE_SIZE ))) { - level =1 ; - pfn &= ~((PMD_SIZE >>PAGE_SHIFT ) -1 ); - } - } -/* -* Compute the PTE value that we need to insert. +* Read the PTE from the process' radix tree and use that +* so we get the shift and attribute bits. */ -if (page) { - pgflags = _PAGE_READ | _PAGE_EXEC | _PAGE_PRESENT | _PAGE_PTE | - _PAGE_ACCESSED; -if (writing || upgrade_write) - pgflags |= _PAGE_WRITE | _PAGE_DIRTY; - pte =pfn_pte (pfn,__pgprot (pgflags)); +local_irq_disable (); + ptep =__find_linux_pte (vcpu->arch.pgdir, hva,NULL , &shift); + pte = *ptep; +local_irq_enable (); + +/* Get pte level from shift/size */ +if (shift =PUD_SHIFT && + (gpa & (PUD_SIZE -PAGE_SIZE )) = + (hva & (PUD_SIZE -PAGE_SIZE ))) { + level =2 ; + }else if (shift =PMD_SHIFT && + (gpa & (PMD_SIZE -PAGE_SIZE )) = + (hva & (PMD_SIZE -PAGE_SIZE ))) { + level =1 ; }else { -/* -* Read the PTE from the process' radix tree and use that -* so we get the attribute bits. -*/ -local_irq_disable (); - ptep =__find_linux_pte (vcpu->arch.pgdir, hva,NULL , &shift); - pte = *ptep; -local_irq_enable (); -if (shift =PUD_SHIFT && - (gpa & (PUD_SIZE -PAGE_SIZE )) = - (hva & (PUD_SIZE -PAGE_SIZE ))) { - level =2 ; - }else if (shift =PMD_SHIFT && - (gpa & (PMD_SIZE -PAGE_SIZE )) = - (hva & (PMD_SIZE -PAGE_SIZE ))) { - level =1 ; - }else if (shift && shift !=PAGE_SHIFT ) { -/* Adjust PFN */ -unsigned long mask = (1ul << shift) -PAGE_SIZE ; - pte =__pte (pte_val (pte) | (hva & mask)); - } - pte =__pte (pte_val (pte) | _PAGE_EXEC | _PAGE_ACCESSED); -if (writing || upgrade_write) { -if (pte_val (pte) & _PAGE_WRITE) - pte =__pte (pte_val (pte) | _PAGE_DIRTY); - }else { - pte =__pte (pte_val (pte) & ~(_PAGE_WRITE | _PAGE_DIRTY)); + level =0 ; +if (shift >PAGE_SHIFT ) { +/* +* If the pte maps more than one page, bring over +* bits from the virtual address to get the real +* address of the specific single page we want. +*/ +unsigned long rpnmask = (1ul << shift) -PAGE_SIZE ; + pte =__pte (pte_val (pte) | (hva & rpnmask)); } } + pte =__pte (pte_val (pte) | _PAGE_EXEC | _PAGE_ACCESSED); +if (writing || upgrade_write) { +if (pte_val (pte) & _PAGE_WRITE) + pte =__pte (pte_val (pte) | _PAGE_DIRTY); + }else { + pte =__pte (pte_val (pte) & ~(_PAGE_WRITE | _PAGE_DIRTY)); + } +/* Allocate space in the tree and write the PTE */ ret =kvmppc_create_pte (kvm, pte, gpa, level, mmu_seq);
Greg Kroah-Hartman
maintainerPATCH 87/135 scsi: iscsi: target: Dont use stack buffer for scatterlist
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laura Abbott <[email protected]>
[ Upstream commit 679fcae46c8b2352bba3485d521da070cfbe68e6 ]
Fedora got a bug report of a crash with iSCSI:
kernel BUG at include/linux/scatterlist.h:143!
...
RIP: 0010:iscsit_do_crypto_hash_buf+0x154/0x180 [iscsi_target_mod] ... Call Trace: ? iscsi_target_tx_thread+0x200/0x200 [iscsi_target_mod] iscsit_get_rx_pdu+0x4cd/0xa90 [iscsi_target_mod] ? native_sched_clock+0x3e/0xa0 ? iscsi_target_tx_thread+0x200/0x200 [iscsi_target_mod] iscsi_target_rx_thread+0x81/0xf0 [iscsi_target_mod] kthread+0x120/0x140 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x3a/0x50
This is a BUG_ON for using a stack buffer with a scatterlist. There are two cases that trigger this bug. Switch to using a dynamically allocated buffer for one case and do not assign a NULL buffer in another case.
--- drivers/target/iscsi/iscsi_target.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
drivers/target/iscsi/iscsi_target.c +14 -8
@@ -1419,7 +1419,8 @@ static void iscsit_do_crypto_hash_buf(stsg_init_table (sg,ARRAY_SIZE (sg));sg_set_buf (sg, buf, payload_length); -sg_set_buf (sg +1 , pad_bytes, padding); +if (padding) +sg_set_buf (sg +1 , pad_bytes, padding);ahash_request_set_crypt (hash, sg, data_crc, payload_length + padding);
@@ -3913,10 +3914,14 @@ static bool iscsi_target_check_conn_statstatic void iscsit_get_rx_pdu (struct iscsi_conn *conn) {int ret; -u8 buffer[ISCSI_HDR_LEN ], opcode; +u8 *buffer, opcode;u32 checksum =0 , digest =0 ;struct kvec iov; + buffer =kcalloc (ISCSI_HDR_LEN ,sizeof (*buffer),GFP_KERNEL ); +if (!buffer) +return ; +while (!kthread_should_stop ()) {/* * Ensure that both TX and RX per connection kthreads
@@ -3924,7 +3929,6 @@ static void iscsit_get_rx_pdu(struct isc*/ iscsit_thread_check_cpumask (conn, current,0 ); -memset (buffer,0 ,ISCSI_HDR_LEN );memset (&iov,0 ,sizeof (struct kvec )); iov.iov_base = buffer;
@@ -3933,7 +3937,7 @@ static void iscsit_get_rx_pdu(struct isc ret =rx_data (conn, &iov,1 ,ISCSI_HDR_LEN );if (ret !=ISCSI_HDR_LEN ) {iscsit_rx_thread_wait_for_tcp (conn); -return ; +break ; }if (conn->conn_ops->HeaderDigest) {
@@ -3943,7 +3947,7 @@ static void iscsit_get_rx_pdu(struct isc ret =rx_data (conn, &iov,1 ,ISCSI_CRC_LEN );if (ret !=ISCSI_CRC_LEN ) {iscsit_rx_thread_wait_for_tcp (conn); -return ; +break ; } iscsit_do_crypto_hash_buf(conn->conn_rx_hash, buffer,
@@ -3967,7 +3971,7 @@ static void iscsit_get_rx_pdu(struct isc }if (conn->conn_state ==TARG_CONN_STATE_IN_LOGOUT ) -return ; +break ; opcode = buffer[0 ] &ISCSI_OPCODE_MASK ;
@@ -3978,13 +3982,15 @@ static void iscsit_get_rx_pdu(struct isc " while in Discovery Session, rejecting.\n", opcode);iscsit_add_reject (conn,ISCSI_REASON_PROTOCOL_ERROR , buffer); -return ; +break ; } ret =iscsi_target_rx_opcode (conn, buffer);if (ret <0 ) -return ; +break ; } + +kfree (buffer); }int iscsi_target_rx_thread (void *arg)
Greg Kroah-Hartman
maintainerPATCH 89/135 sound: enable interrupt after dma buffer initialization
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Zhao <[email protected]>
[ Upstream commit b61749a89f826eb61fc59794d9e4697bd246eb61 ]
In snd_hdac_bus_init_chip(), we enable interrupt before snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has been acquired and irq handler uses the dma buffer, kernel may crash when interrupt comes in.
Fix the problem by postponing enabling irq after dma buffer initialization. And warn once on null dma buffer pointer during the initialization.
--- sound/hda/hdac_controller.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
sound/hda/hdac_controller.c +6 -2
@@ -40,6 +40,8 @@ static void azx_clear_corbrp(struct hdac*/ void snd_hdac_bus_init_cmd_io (struct hdac_bus *bus) { +WARN_ON_ONCE (!bus->rb.area); +spin_lock_irq (&bus->reg_lock);/* CORB set up */ bus->corb.addr = bus->rb.addr;
@@ -479,13 +481,15 @@ bool snd_hdac_bus_init_chip(struct hdac_/* reset controller */ azx_reset (bus, full_reset); -/* initialize interrupts */ +/* clear interrupts */ azx_int_clear (bus); -azx_int_enable (bus);/* initialize the codec command I/O */ snd_hdac_bus_init_cmd_io (bus); +/* enable interrupts after CORB/RIRB buffers are initialized above */ +azx_int_enable (bus); +/* program the position buffer */ if (bus->use_posbuf && bus->posbuf.addr) {snd_hdac_chip_writel (bus,DPLBASE , (u32 )bus->posbuf.addr);
Greg Kroah-Hartman
maintainerPATCH 93/135 hwmon: (nct6775) Fix virtual temperature sources for NCT6796D
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 37196ba4ae95a2077d78715eb12e879e57613d43 ]
The following kernel log message is reported for the nct6775 driver on ASUS WS X299 SAGE.
nct6775: Found NCT6796D or compatible chip at 0x2e:0x290 nct6775 nct6775.656: Invalid temperature source 11 at index 0,
source register 0x100, temp register 0x73 nct6775 nct6775.656: Invalid temperature source 11 at index 2, source register 0x300, temp register 0x77 nct6775 nct6775.656: Invalid temperature source 11 at index 3, source register 0x800, temp register 0x79 nct6775 nct6775.656: Invalid temperature source 11 at index 4, source register 0x900, temp register 0x7b
A recent version of the datasheet lists temperature source 11 as reserved. However, an older version of the datasheet lists temperature sources 10 and 11 as supported virtual temperature sources. Apparently the older version of the datasheet is correct, so list those temperature sources as supported.
Virtual temperature sources are different than other temperature sources:
Values are not read from a temperature sensor, but written either from BIOS or an embedded controller. As such, each virtual temperature has to be reported. Since there is now more than one temperature source, we have to keep virtual temperature sources in a chip-specific mask and can no longer rely on the assumption that there is only one virtual temperature source with a fixed index. This accounts for most of the complexity of this patch.
--- drivers/hwmon/nct6775.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-)
drivers/hwmon/nct6775.c +22 -6
@@ -207,8 +207,6 @@ superio_exit(int ioreg)#define NUM_FAN 7 -#define TEMP_SOURCE_VIRTUAL 0x1f -/* Common and NCT6775 specific data */ /* Voltage min/max registers for nr=7..14 are in bank 5 */
@@ -374,6 +372,7 @@ static const char *const nct6775_temp_la };#define NCT6775_TEMP_MASK 0x001ffffe +#define NCT6775_VIRT_TEMP_MASK 0x00000000static const u16 NCT6775_REG_TEMP_ALTERNATE [32 ] = { [13 ] =0x661 ,
@@ -462,6 +461,7 @@ static const char *const nct6776_temp_la };#define NCT6776_TEMP_MASK 0x007ffffe +#define NCT6776_VIRT_TEMP_MASK 0x00000000static const u16 NCT6776_REG_TEMP_ALTERNATE [32 ] = { [14 ] =0x401 ,
@@ -560,7 +560,9 @@ static const char *const nct6779_temp_la };#define NCT6779_TEMP_MASK 0x07ffff7e +#define NCT6779_VIRT_TEMP_MASK 0x00000000#define NCT6791_TEMP_MASK 0x87ffff7e +#define NCT6791_VIRT_TEMP_MASK 0x80000000static const u16 NCT6779_REG_TEMP_ALTERNATE [32 ] = {0x490 ,0x491 ,0x492 ,0x493 ,0x494 ,0x495 ,0 ,0 ,
@@ -639,6 +641,7 @@ static const char *const nct6792_temp_la };#define NCT6792_TEMP_MASK 0x9fffff7e +#define NCT6792_VIRT_TEMP_MASK 0x80000000static const char *const nct6793_temp_label[] = {"" ,
@@ -676,6 +679,7 @@ static const char *const nct6793_temp_la };#define NCT6793_TEMP_MASK 0xbfff037e +#define NCT6793_VIRT_TEMP_MASK 0x80000000static const char *const nct6795_temp_label[] = {"" ,
@@ -713,6 +717,7 @@ static const char *const nct6795_temp_la };#define NCT6795_TEMP_MASK 0xbfffff7e +#define NCT6795_VIRT_TEMP_MASK 0x80000000static const char *const nct6796_temp_label[] = {"" ,
@@ -725,8 +730,8 @@ static const char *const nct6796_temp_la"AUXTIN4" ,"SMBUSMASTER 0" ,"SMBUSMASTER 1" , -"" , -"" , +"Virtual_TEMP" , +"Virtual_TEMP" ,"" ,"" , "",
@@ -749,7 +754,8 @@ static const char *const nct6796_temp_la "Virtual_TEMP" }; -#define NCT6796_TEMP_MASK 0xbfff03fe +#define NCT6796_TEMP_MASK 0xbfff0ffe +#define NCT6796_VIRT_TEMP_MASK 0x80000c00/* NCT6102D/NCT6106D specific data */
@@ -970,6 +976,7 @@ struct nct6775_data {u16 reg_temp_config[NUM_TEMP ];const char *const *temp_label;u32 temp_mask; +u32 virt_temp_mask;u16 REG_CONFIG ;u16 REG_VBAT ;
@@ -3644,6 +3651,7 @@ static int nct6775_probe(struct platform data->temp_label = nct6776_temp_label; data->temp_mask =NCT6776_TEMP_MASK ; + data->virt_temp_mask =NCT6776_VIRT_TEMP_MASK ; data->REG_VBAT =NCT6106_REG_VBAT ; data->REG_DIODE =NCT6106_REG_DIODE ;
@@ -3722,6 +3730,7 @@ static int nct6775_probe(struct platform data->temp_label = nct6775_temp_label; data->temp_mask =NCT6775_TEMP_MASK ; + data->virt_temp_mask =NCT6775_VIRT_TEMP_MASK ; data->REG_CONFIG =NCT6775_REG_CONFIG ; data->REG_VBAT =NCT6775_REG_VBAT ;
@@ -3794,6 +3803,7 @@ static int nct6775_probe(struct platform data->temp_label = nct6776_temp_label; data->temp_mask =NCT6776_TEMP_MASK ; + data->virt_temp_mask =NCT6776_VIRT_TEMP_MASK ; data->REG_CONFIG =NCT6775_REG_CONFIG ; data->REG_VBAT =NCT6775_REG_VBAT ;
@@ -3866,6 +3876,7 @@ static int nct6775_probe(struct platform data->temp_label = nct6779_temp_label; data->temp_mask =NCT6779_TEMP_MASK ; + data->virt_temp_mask =NCT6779_VIRT_TEMP_MASK ; data->REG_CONFIG =NCT6775_REG_CONFIG ; data->REG_VBAT =NCT6775_REG_VBAT ;
@@ -3949,22 +3960,27 @@ static int nct6775_probe(struct platformcase nct6791: data->temp_label = nct6779_temp_label; data->temp_mask =NCT6791_TEMP_MASK ; + data->virt_temp_mask =NCT6791_VIRT_TEMP_MASK ;break ;case nct6792: data->temp_label = nct6792_temp_label; data->temp_mask =NCT6792_TEMP_MASK ; + data->virt_temp_mask =NCT6792_VIRT_TEMP_MASK ;break ;case nct6793: data->temp_label = nct6793_temp_label; data->temp_mask =NCT6793_TEMP_MASK ; + data->virt_temp_mask =NCT6793_VIRT_TEMP_MASK ;break ;case nct6795: data->temp_label = nct6795_temp_label; data->temp_mask =NCT6795_TEMP_MASK ; + data->virt_temp_mask =NCT6795_VIRT_TEMP_MASK ;break ;case nct6796: data->temp_label = nct6796_temp_label; data->temp_mask =NCT6796_TEMP_MASK ; + data->virt_temp_mask =NCT6796_VIRT_TEMP_MASK ;break ; }
@@ -4148,7 +4164,7 @@ static int nct6775_probe(struct platform* for each fan reflects a different temperature, and there * are no duplicates. */ -if (src !=TEMP_SOURCE_VIRTUAL ) { +if (!(data->virt_temp_mask &BIT (src))) {if (mask &BIT (src))continue ; mask |=BIT (src);
Greg Kroah-Hartman
maintainerPATCH 95/135 stmmac: fix valid numbers of unicast filter entries
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jongsung Kim <[email protected]>
[ Upstream commit edf2ef7242805e53ec2e0841db26e06d8bc7da70 ]
Synopsys DWC Ethernet MAC can be configured to have 1..32, 64, or 128 unicast filter entries. (Table 7-8 MAC Address Registers from databook) Fix dwmac1000_validate_ucast_entries() to accept values between 1 and 32 in addition.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +2 -3
@@ -67,7 +67,7 @@ static int dwmac1000_validate_mcast_bins* Description: * This function validates the number of Unicast address entries supported * by a particular Synopsys 10/100/1000 controller. The Synopsys controller -* supports 1, 32, 64, or 128 Unicast filter entries for it's Unicast filter +* supports 1..32, 64, or 128 Unicast filter entries for it's Unicast filter * logic. This function validates a valid, supported configuration is * selected, and defaults to 1 Unicast address if an unsupported * configuration is selected.
@@ -77,8 +77,7 @@ static int dwmac1000_validate_ucast_entrint x = ucast_entries;switch (x) { -case 1 : -case 32 : + case 1 ... 32:case 64 :case 128 :break ;
Greg Kroah-Hartman
maintainerPATCH 98/135 net: macb: disable scatter-gather for macb on sama5d3
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Ferre <[email protected]>
[ Upstream commit eb4ed8e2d7fecb5f40db38e4498b9ee23cddf196 ]
Create a new configuration for the sama5d3-macb new compatibility string. This configuration disables scatter-gather because we experienced lock down of the macb interface of this particular SoC under very high load.
--- drivers/net/ethernet/cadence/macb_main.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/net/ethernet/cadence/macb_main.c +8 -0
@@ -3765,6 +3765,13 @@ static const struct macb_config at91sam9 .init = macb_init, }; +static const struct macb_config sama5d3macb_config = { + .caps =MACB_CAPS_SG_DISABLED + |MACB_CAPS_USRIO_HAS_CLKEN |MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII , + .clk_init = macb_clk_init, + .init = macb_init, +}; +static const struct macb_config pc302gem_config = { .caps =MACB_CAPS_SG_DISABLED |MACB_CAPS_GIGABIT_MODE_AVAILABLE , .dma_burst_length =16 ,
@@ -3832,6 +3839,7 @@ static const struct of_device_id macb_dt { .compatible = "cdns,gem", .data = &pc302gem_config }, { .compatible = "atmel,sama5d2-gem", .data = &sama5d2_config }, { .compatible = "atmel,sama5d3-gem", .data = &sama5d3_config }, + { .compatible = "atmel,sama5d3-macb", .data = &sama5d3macb_config }, { .compatible = "atmel,sama5d4-gem", .data = &sama5d4_config }, { .compatible = "cdns,at91rm9200-emac", .data = &emac_config }, { .compatible = "cdns,emac", .data = &emac_config },
Greg Kroah-Hartman
maintainerPATCH 113/135 MIPS: Fix CONFIG_CMDLINE handling
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 951d223c6c16ed5d2a71a4d1f13c1e65d6882156 upstream.
Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup") fixed a problem for systems which have CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no bootargs property or an empty one. In this configuration early_init_dt_scan_chosen() copies CONFIG_CMDLINE into boot_command_line, but the MIPS code doesn't know this so it appends CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The result is that boot_command_line contains the arguments from CONFIG_CMDLINE twice.
That commit took the approach of simply setting up boot_command_line from the MIPS code before early_init_dt_scan_chosen() runs, causing it not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no bootargs property is found.
Unfortunately this is problematic for systems which do have a non-empty bootargs property & CONFIG_CMDLINE_BOOL=y. There early_init_dt_scan_chosen() will overwrite boot_command_line with the arguments from DT, which means we lose those from CONFIG_CMDLINE entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs property which we should ignore, it will instead be honoured breaking those configurations too.
Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup") to restore the former behaviour, and fixing the CONFIG_CMDLINE duplication issue by initializing boot_command_line to a non-empty string that early_init_dt_scan_chosen() will not overwrite with CONFIG_CMDLINE.
This is a little ugly, but cleanup in this area is on its way. In the meantime this is at least easy to backport & contains the ugliness within arch/mips/.
References: https://patchwork.linux-mips.org/patch/18804/
Patchwork: https://patchwork.linux-mips.org/patch/20813/
--- arch/mips/kernel/setup.c | 48 +++++++++++++++++++++++++++-------------------- 1 file changed, 28 insertions(+), 20 deletions(-)
arch/mips/kernel/setup.c +28 -20
@@ -835,6 +835,34 @@ static void __init arch_mem_init(char **struct memblock_region *reg;extern void plat_mem_setup (void ); +/* +* Initialize boot_command_line to an innocuous but non-empty string in +* order to prevent early_init_dt_scan_chosen() from copying +* CONFIG_CMDLINE into it without our knowledge. We handle +* CONFIG_CMDLINE ourselves below & don't want to duplicate its +* content because repeating arguments can be problematic. +*/ +strlcpy (boot_command_line," " ,COMMAND_LINE_SIZE ); + +/* call board setup routine */ +plat_mem_setup (); + +/* +* Make sure all kernel memory is in the maps. The "UP" and +* "DOWN" are opposite for initdata since if it crosses over +* into another memory section you don't want that to be +* freed when the initdata is freed. +*/ +arch_mem_addpart (PFN_DOWN (__pa_symbol (&_text)) <<PAGE_SHIFT , +PFN_UP (__pa_symbol (&_edata)) <<PAGE_SHIFT , +BOOT_MEM_RAM ); +arch_mem_addpart (PFN_UP (__pa_symbol (&__init_begin)) <<PAGE_SHIFT , +PFN_DOWN (__pa_symbol (&__init_end)) <<PAGE_SHIFT , +BOOT_MEM_INIT_RAM ); + +pr_info ("Determined physical RAM map:\n" ); +print_memory_map (); +#if defined(CONFIG_CMDLINE_BOOL ) && defined(CONFIG_CMDLINE_OVERRIDE )strlcpy (boot_command_line, builtin_cmdline,COMMAND_LINE_SIZE );#else
@@ -862,26 +890,6 @@ static void __init arch_mem_init(char ** }#endif #endif - -/* call board setup routine */ -plat_mem_setup (); - -/* -* Make sure all kernel memory is in the maps. The "UP" and -* "DOWN" are opposite for initdata since if it crosses over -* into another memory section you don't want that to be -* freed when the initdata is freed. -*/ -arch_mem_addpart (PFN_DOWN (__pa_symbol (&_text)) <<PAGE_SHIFT , -PFN_UP (__pa_symbol (&_edata)) <<PAGE_SHIFT , -BOOT_MEM_RAM ); -arch_mem_addpart (PFN_UP (__pa_symbol (&__init_begin)) <<PAGE_SHIFT , -PFN_DOWN (__pa_symbol (&__init_end)) <<PAGE_SHIFT , -BOOT_MEM_INIT_RAM ); - -pr_info ("Determined physical RAM map:\n" ); -print_memory_map (); -strlcpy (command_line, boot_command_line,COMMAND_LINE_SIZE ); *cmdline_p = command_line;
Greg Kroah-Hartman
maintainerPATCH 114/135 MIPS: VDSO: Always map near top of user memory
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit ea7e0480a4b695d0aa6b3fa99bd658a003122113 upstream.
When using the legacy mmap layout, for example triggered using ulimit -s unlimited, get_unmapped_area() fills memory from bottom to top starting from a fairly low address near TASK_UNMAPPED_BASE.
This placement is suboptimal if the user application wishes to allocate large amounts of heap memory using the brk syscall. With the VDSO being located low in the user's virtual address space, the amount of space available for access using brk is limited much more than it was prior to the introduction of the VDSO.
For example:
# ulimit -s unlimited; cat /proc/self/maps 00400000-004ec000 r-xp 00000000 08:00 71436 /usr/bin/coreutils 004fc000-004fd000 rwxp 000ec000 08:00 71436 /usr/bin/coreutils 004fd000-0050f000 rwxp 00000000 00:00 0 00cc3000-00ce4000 rwxp 00000000 00:00 0 [heap] 2ab96000-2ab98000 r--p 00000000 00:00 0 [vvar] 2ab98000-2ab99000 r-xp 00000000 00:00 0 [vdso] 2ab99000-2ab9d000 rwxp 00000000 00:00 0 ...
Resolve this by adjusting STACK_TOP to reserve space for the VDSO & providing an address hint to get_unmapped_area() causing it to use this space even when using the legacy mmap layout.
We reserve enough space for the VDSO, plus 1MB or 256MB for 32 bit & 64 bit systems respectively within which we randomize the VDSO base address. Previously this randomization was taken care of by the mmap base address randomization performed by arch_mmap_rnd(). The 1MB & 256MB sizes are somewhat arbitrary but chosen such that we have some randomization without taking up too much of the user's virtual address space, which is often in short supply for 32 bit systems.
With this the VDSO is always mapped at a high address, leaving lots of space for statically linked programs to make use of brk:
# ulimit -s unlimited; cat /proc/self/maps 00400000-004ec000 r-xp 00000000 08:00 71436 /usr/bin/coreutils 004fc000-004fd000 rwxp 000ec000 08:00 71436 /usr/bin/coreutils 004fd000-0050f000 rwxp 00000000 00:00 0 00c28000-00c49000 rwxp 00000000 00:00 0 [heap] ... 7f67c000-7f69d000 rwxp 00000000 00:00 0 [stack] 7f7fc000-7f7fd000 rwxp 00000000 00:00 0 7fcf1000-7fcf3000 r--p 00000000 00:00 0 [vvar] 7fcf3000-7fcf4000 r-xp 00000000 00:00 0 [vdso]
--- arch/mips/include/asm/processor.h | 10 +++++----- arch/mips/kernel/process.c | 25 +++++++++++++++++++++++++ arch/mips/kernel/vdso.c | 18 +++++++++++++++++- 3 files changed, 47 insertions(+), 6 deletions(-)
arch/mips/include/asm/processor.h +5 -5
@@ -13,6 +13,7 @@#include <linux/atomic.h> #include <linux/cpumask.h> +#include <linux/sizes.h> #include <linux/threads.h> #include <asm/cachectl.h>
@@ -80,11 +81,10 @@ extern unsigned int vced_count, vcei_cou#endif -/* -* One page above the stack is used for branch delay slot "emulation". -* See dsemul.c for details. -*/ -#define STACK_TOP ((TASK_SIZE & PAGE_MASK) - PAGE_SIZE) +#define VDSO_RANDOMIZE_SIZE (TASK_IS_32BIT_ADDR ? SZ_1M : SZ_256M) + +extern unsigned long mips_stack_top (void ); +#define STACK_TOP mips_stack_top()/* * This decides where the kernel will search for a free chunk of vm
arch/mips/kernel/process.c +25 -0
@@ -31,6 +31,7 @@#include <linux/prctl.h> #include <linux/nmi.h> +#include <asm/abi.h> #include <asm/asm.h> #include <asm/bootinfo.h> #include <asm/cpu.h>
@@ -38,6 +39,7 @@#include <asm/dsp.h> #include <asm/fpu.h> #include <asm/irq.h> +#include <asm/mips-cps.h> #include <asm/msa.h> #include <asm/pgtable.h> #include <asm/mipsregs.h>
@@ -644,6 +646,29 @@ out:return pc; } +unsigned long mips_stack_top (void ) +{ +unsigned long top =TASK_SIZE &PAGE_MASK ; + +/* One page for branch delay slot "emulation" */ + top -=PAGE_SIZE ; + +/* Space for the VDSO, data page & GIC user page */ + top -=PAGE_ALIGN (current->thread.abi->vdso->size); + top -=PAGE_SIZE ; + top -=mips_gic_present () ?PAGE_SIZE :0 ; + +/* Space for cache colour alignment */ +if (cpu_has_dc_aliases) + top -= shm_align_mask +1 ; + +/* Space to randomize the VDSO base */ +if (current->flags &PF_RANDOMIZE ) + top -=VDSO_RANDOMIZE_SIZE ; + +return top; +} +/* * Don't forget that the stack pointer must be aligned on a 8 bytes * boundary for 32-bits ABI and 16 bytes for 64-bits ABI.
arch/mips/kernel/vdso.c +17 -1
@@ -15,6 +15,7 @@#include <linux/ioport.h> #include <linux/kernel.h> #include <linux/mm.h> +#include <linux/random.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/timekeeper_internal.h>
@@ -97,6 +98,21 @@ void update_vsyscall_tz(void) } } +static unsigned long vdso_base (void ) +{ +unsigned long base; + +/* Skip the delay slot emulation page */ + base =STACK_TOP +PAGE_SIZE ; + +if (current->flags &PF_RANDOMIZE ) { + base +=get_random_int () & (VDSO_RANDOMIZE_SIZE -1 ); + base =PAGE_ALIGN (base); + } + +return base; +} +int arch_setup_additional_pages (struct linux_binprm *bprm,int uses_interp) {struct mips_vdso_image *image = current->thread.abi->vdso;
@@ -137,7 +153,7 @@ int arch_setup_additional_pages(struct lif (cpu_has_dc_aliases) size += shm_align_mask +1 ; - base =get_unmapped_area (NULL ,0 , size,0 ,0 ); + base =get_unmapped_area (NULL ,vdso_base (), size,0 ,0 );if (IS_ERR_VALUE (base)) { ret = base; goto out;
Greg Kroah-Hartman
maintainerPATCH 115/135 mach64: detect the dot clock divider correctly on sparc
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <[email protected]>
commit 76ebebd2464c5c8a4453c98b6dbf9c95a599e810 upstream.
On Sun Ultra 5, it happens that the dot clock is not set up properly for some videomodes. For example, if we set the videomode "r1024x768x60" in the firmware, Linux would incorrectly set a videomode with refresh rate 180Hz when booting (suprisingly, my LCD monitor can display it, although display quality is very low).
The reason is this: Older mach64 cards set the divider in the register VCLK_POST_DIV. The register has four 2-bit fields (the field that is actually used is specified in the lowest two bits of the register CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards, there's another bit added - the top four bits of PLL_EXT_CNTL extend the divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12". The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets them, so it can work regardless if the card supports them. However, the sparc64 firmware may set these extended dividers during boot - and the mach64 driver detects incorrect dot clock in this case.
This patch makes the driver read the additional divider bit from PLL_EXT_CNTL and calculate the initial refresh rate properly.
--- drivers/video/fbdev/aty/atyfb.h | 3 ++- drivers/video/fbdev/aty/atyfb_base.c | 7 ++++--- drivers/video/fbdev/aty/mach64_ct.c | 10 +++++----- 3 files changed, 11 insertions(+), 9 deletions(-)
drivers/video/fbdev/aty/atyfb.h +2 -1
@@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_extern void aty_set_pll_ct (const struct fb_info *info,const union aty_pll *pll);extern u8 aty_ld_pll_ct (int offset,const struct atyfb_par *par); +extern const u8 aty_postdividers[8 ]; +/* * Hardware cursor support
@@ -359,7 +361,6 @@ static inline void wait_for_idle(structextern void aty_reset_engine (const struct atyfb_par *par);extern void aty_init_engine (struct atyfb_par *par,struct fb_info *info); -extern u8 aty_ld_pll_ct (int offset,const struct atyfb_par *par);void atyfb_copyarea (struct fb_info *info,const struct fb_copyarea *area);void atyfb_fillrect (struct fb_info *info,const struct fb_fillrect *rect);
drivers/video/fbdev/aty/atyfb_base.c +4 -3
@@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_/* * PLL Reference Divider M: */ -M = pll_regs[2 ]; +M = pll_regs[PLL_REF_DIV ];/* * PLL Feedback Divider N (Dependent on CLOCK_CNTL): */ -N = pll_regs[7 + (clock_cntl &3 )]; +N = pll_regs[VCLK0_FB_DIV + (clock_cntl &3 )];/* * PLL Post Divider P (Dependent on CLOCK_CNTL): */ -P =1 << (pll_regs[6 ] >> ((clock_cntl &3 ) <<1 )); +P = aty_postdividers[((pll_regs[VCLK_POST_DIV ] >> ((clock_cntl &3 ) <<1 )) &3 ) | + ((pll_regs[PLL_EXT_CNTL ] >> (2 + (clock_cntl &3 ))) &4 )];/* * PLL Divider Q:
drivers/video/fbdev/aty/mach64_ct.c +5 -5
@@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8*/ #define Maximum_DSP_PRECISION 7 -static u8 postdividers[] = {1 ,2 ,4 ,8 ,3 }; +const u8 aty_postdividers[8 ] = {1 ,2 ,4 ,8 ,3 ,5 ,6 ,12 };static int aty_dsp_gt (const struct fb_info *info,u32 bpp,struct pll_ct *pll) {
@@ -222,7 +222,7 @@ static int aty_valid_pll_ct(const struct pll->vclk_post_div += (q <64 *8 ); pll->vclk_post_div += (q <32 *8 ); } - pll->vclk_post_div_real = postdividers[pll->vclk_post_div]; + pll->vclk_post_div_real = aty_postdividers[pll->vclk_post_div];// pll->vclk_post_div <<= 6; pll->vclk_fb_div = q * pll->vclk_post_div_real /8 ; pllvclk = (1000000 * 2 * pll->vclk_fb_div) /
@@ -513,7 +513,7 @@ static int aty_init_pll_ct(const structu8 mclk_fb_div, pll_ext_cntl; pll->ct.pll_ref_div =aty_ld_pll_ct (PLL_REF_DIV , par); pll_ext_cntl =aty_ld_pll_ct (PLL_EXT_CNTL , par); - pll->ct.xclk_post_div_real = postdividers[pll_ext_cntl &0x07 ]; + pll->ct.xclk_post_div_real = aty_postdividers[pll_ext_cntl &0x07 ]; mclk_fb_div =aty_ld_pll_ct (MCLK_FB_DIV , par);if (pll_ext_cntl &PLL_MFB_TIMES_4_2B ) mclk_fb_div <<=1 ;
@@ -535,7 +535,7 @@ static int aty_init_pll_ct(const struct xpost_div += (q <64 *8 ); xpost_div += (q <32 *8 ); } - pll->ct.xclk_post_div_real = postdividers[xpost_div]; + pll->ct.xclk_post_div_real = aty_postdividers[xpost_div]; pll->ct.mclk_fb_div = q * pll->ct.xclk_post_div_real /8 ;#ifdef CONFIG_PPC
@@ -584,7 +584,7 @@ static int aty_init_pll_ct(const struct mpost_div += (q <64 *8 ); mpost_div += (q <32 *8 ); } - sclk_post_div_real = postdividers[mpost_div]; + sclk_post_div_real = aty_postdividers[mpost_div]; pll->ct.sclk_fb_div = q * sclk_post_div_real /8 ; pll->ct.spll_cntl2 = mpost_div <<4 ;#ifdef DEBUG
Greg Kroah-Hartman
maintainerPATCH 119/135 perf script python: Fix export-to-sqlite.py sample columns
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit d005efe18db0b4a123dd92ea8e77e27aee8f99fd upstream.
With the "branches" export option, not all sample columns are exported. However the unwanted columns are not at the end of the tuple, as assumed by the code. Fix by taking the first 15 and last 3 values, instead of the first 18.
--- tools/perf/scripts/python/export-to-sqlite.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
tools/perf/scripts/python/export-to-sqlite.py +5 -1
@@ -440,7 +440,11 @@ def branch_type_table(*x): def sample_table(*x): if branches: - bind_exec(sample_query, 18, x) + for xx in x[0:15]: + sample_query.addBindValue(str(xx)) + for xx in x[19:22]: + sample_query.addBindValue(str(xx)) + do_query_(sample_query) else: bind_exec(sample_query, 22, x)
Greg Kroah-Hartman
maintainerPATCH 120/135 s390/cio: Fix how vfio-ccw checks pinned pages
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Farman <[email protected]>
commit 24abf2901b18bf941b9f21ea2ce5791f61097ae4 upstream.
We have two nested loops to check the entries within the pfn_array_table arrays. But we mistakenly use the outer array as an index in our check, and completely ignore the indexing performed by the inner loop.
Message-Id: <[email protected]>
--- drivers/s390/cio/vfio_ccw_cp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/s390/cio/vfio_ccw_cp.c +1 -1
@@ -163,7 +163,7 @@ static bool pfn_array_table_iova_pinned(for (i =0 ; i < pat->pat_nr; i++, pa++)for (j =0 ; j < pa->pa_nr; j++) -if (pa->pa_iova_pfn[i] == iova_pfn) +if (pa->pa_iova_pfn[j] == iova_pfn)return true;return false;
Greg Kroah-Hartman
maintainerPATCH 124/135 dm linear: fix linear_end_io conditional definition
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 118aa47c7072bce05fc39bd40a1c0a90caed72ab upstream.
The dm-linear target is independent of the dm-zoned target. For code requiring support for zoned block devices, use CONFIG_BLK_DEV_ZONED instead of CONFIG_DM_ZONED.
While at it, similarly to dm linear, also enable the DM_TARGET_ZONED_HM feature in dm-flakey only if CONFIG_BLK_DEV_ZONED is defined.
--- drivers/md/dm-flakey.c | 2 ++ drivers/md/dm-linear.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/md/dm-flakey.c +2 -0
@@ -467,7 +467,9 @@ static int flakey_iterate_devices(structstatic struct target_type flakey_target = { .name ="flakey" , .version = {1 ,5 ,0 }, +#ifdef CONFIG_BLK_DEV_ZONED .features =DM_TARGET_ZONED_HM , +#endif .module =THIS_MODULE , .ctr = flakey_ctr, .dtr = flakey_dtr,
drivers/md/dm-linear.c +2 -2
@@ -102,7 +102,7 @@ static int linear_map(struct dm_target *return DM_MAPIO_REMAPPED ; } -#ifdef CONFIG_DM_ZONED +#ifdef CONFIG_BLK_DEV_ZONED static int linear_end_io (struct dm_target *ti,struct bio *bio,blk_status_t *error) {
@@ -210,7 +210,7 @@ static size_t linear_dax_copy_to_iter(ststatic struct target_type linear_target = { .name ="linear" , .version = {1 ,4 ,0 }, -#ifdef CONFIG_DM_ZONED +#ifdef CONFIG_BLK_DEV_ZONED .end_io = linear_end_io, .features =DM_TARGET_PASSES_INTEGRITY |DM_TARGET_ZONED_HM , #else
Greg Kroah-Hartman
maintainerPATCH 135/135 i2c: i2c-scmi: fix for i2c_smbus_write_block_data
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Edgar Cherkasov <[email protected]>
commit 08d9db00fe0e300d6df976e6c294f974988226dd upstream.
The i2c-scmi driver crashes when the SMBus Write Block transaction is executed:
WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0 Call Trace: ? get_page_from_freelist+0x49d/0x11f0 ? alloc_pages_current+0x6a/0xe0 ? new_slab+0x499/0x690 __alloc_pages_nodemask+0x265/0x280 alloc_pages_current+0x6a/0xe0 kmalloc_order+0x18/0x40 kmalloc_order_trace+0x24/0xb0 ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c __kmalloc+0x203/0x220 acpi_os_allocate_zeroed+0x34/0x36 acpi_ut_copy_eobject_to_iobject+0x266/0x31e acpi_evaluate_object+0x166/0x3b2 acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi] i2c_smbus_xfer+0xda/0x370 i2cdev_ioctl_smbus+0x1bd/0x270 i2cdev_ioctl+0xaa/0x250 do_vfs_ioctl+0xa4/0x600 SyS_ioctl+0x79/0x90 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185)
This problem occurs because the length of ACPI Buffer object is not defined/initialized in the code before a corresponding ACPI method is called. The obvious patch below fixes this issue.
--- drivers/i2c/busses/i2c-scmi.c | 1 + 1 file changed, 1 insertion(+)
drivers/i2c/busses/i2c-scmi.c +1 -0
@@ -152,6 +152,7 @@ acpi_smbus_cmi_access(struct i2c_adapter mt_params[3 ].type =ACPI_TYPE_INTEGER ; mt_params[3 ].integer.value = len; mt_params[4 ].type =ACPI_TYPE_BUFFER ; + mt_params[4 ].buffer.length = len; mt_params[4 ].buffer.pointer = data->block +1 ; }break ;
Greg Kroah-Hartman
maintainerPATCH 1/135 bnxt_en: Fix TX timeout during netpoll.
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Chan <[email protected]>
[ Upstream commit 73f21c653f930f438d53eed29b5e4c65c8a0f906 ]
The current netpoll implementation in the bnxt_en driver has problems that may miss TX completion events. bnxt_poll_work() in effect is only handling at most 1 TX packet before exiting. In addition, there may be in flight TX completions that ->poll() may miss even after we fix bnxt_poll_work() to handle all visible TX completions. netpoll may not call ->poll() again and HW may not generate IRQ because the driver does not ARM the IRQ when the budget (0 for netpoll) is reached.
We fix it by handling all TX completions and to always ARM the IRQ when we exit ->poll() with 0 budget.
Also, the logic to ACK the completion ring in case it is almost filled with TX completions need to be adjusted to take care of the 0 budget case, as discussed with Eric Dumazet <[email protected]>
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +10 -3
@@ -1882,8 +1882,11 @@ static int bnxt_poll_work(struct bnxt *bif (TX_CMP_TYPE (txcmp) ==CMP_TYPE_TX_L2_CMP ) { tx_pkts++;/* return full budget so NAPI will complete. */ -if (unlikely (tx_pkts > bp->tx_wake_thresh)) +if (unlikely (tx_pkts > bp->tx_wake_thresh)) { rx_pkts = budget; + raw_cons =NEXT_RAW_CMP (raw_cons); +break ; + } }else if ((TX_CMP_TYPE (txcmp) &0x30 ) ==0x10 ) {if (likely (budget)) rc =bnxt_rx_pkt (bp, bnapi, &raw_cons, &event);
@@ -1911,7 +1914,7 @@ static int bnxt_poll_work(struct bnxt *b } raw_cons =NEXT_RAW_CMP (raw_cons); -if (rx_pkts == budget) +if (rx_pkts && rx_pkts == budget)break ; }
@@ -2025,8 +2028,12 @@ static int bnxt_poll(struct napi_structwhile (1 ) { work_done +=bnxt_poll_work (bp, bnapi, budget - work_done); -if (work_done >= budget) +if (work_done >= budget) { +if (!budget) +BNXT_CP_DB_REARM (cpr->cp_doorbell, + cpr->cp_raw_cons);break ; + }if (!bnxt_has_work (bp, cpr)) {if (napi_complete_done (napi, work_done))
Greg Kroah-Hartman
maintainerPATCH 10/135 net: ipv4: update fnhe_pmtu when first hops MTU changes
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
[ Upstream commit af7d6cce53694a88d6a1bb60c9a239a6a5144459 ]
Since commit 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions"), exceptions get deprecated separately from cached routes. In particular, administrative changes don't clear PMTU anymore.
As Stefano described in commit e9fa1495d738 ("ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes"), the PMTU discovered before the local MTU change can become stale:
- if the local MTU is now lower than the PMTU, that PMTU is now incorrect
- if the local MTU was the lowest value in the path, and is increased, we might discover a higher PMTU
Similarly to what commit e9fa1495d738 did for IPv6, update PMTU in those cases.
If the exception was locked, the discovered PMTU was smaller than the minimal accepted PMTU. In that case, if the new local MTU is smaller than the current PMTU, let PMTU discovery figure out if locking of the exception is still needed.
To do this, we need to know the old link MTU in the NETDEV_CHANGEMTU notifier. By the time the notifier is called, dev->mtu has been changed. This patch adds the old MTU as additional information in the notifier structure, and a new call_netdevice_notifiers_u32() function.
--- include/linux/netdevice.h | 7 ++++++ include/net/ip_fib.h | 1 net/core/dev.c | 28 +++++++++++++++++++++++-- net/ipv4/fib_frontend.c | 12 +++++++---- net/ipv4/fib_semantics.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 92 insertions(+), 6 deletions(-)
include/linux/netdevice.h +7 -0
@@ -2420,6 +2420,13 @@ struct netdev_notifier_info {struct netlink_ext_ack *extack; }; +struct netdev_notifier_info_ext { +struct netdev_notifier_info info;/* must be first */ +union { +u32 mtu; + } ext; +}; +struct netdev_notifier_change_info {struct netdev_notifier_info info;/* must be first */ unsigned int flags_changed;
include/net/ip_fib.h +1 -0
@@ -394,6 +394,7 @@ int ip_fib_check_default(__be32 gw, struint fib_sync_down_dev (struct net_device *dev,unsigned long event,bool force);int fib_sync_down_addr (struct net_device *dev,__be32 local);int fib_sync_up (struct net_device *dev,unsigned int nh_flags); +void fib_sync_mtu (struct net_device *dev,u32 orig_mtu);#ifdef CONFIG_IP_ROUTE_MULTIPATH int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
net/core/dev.c +26 -2
@@ -1754,6 +1754,28 @@ int call_netdevice_notifiers(unsigned lo }EXPORT_SYMBOL (call_netdevice_notifiers); +/** +* call_netdevice_notifiers_mtu - call all network notifier blocks +* @val: value passed unmodified to notifier function +* @dev: net_device pointer passed unmodified to notifier function +* @arg: additional u32 argument passed to the notifier function +* +* Call all network notifier blocks. Parameters and return value +* are as for raw_notifier_call_chain(). +*/ +static int call_netdevice_notifiers_mtu (unsigned long val, +struct net_device *dev,u32 arg) +{ +struct netdev_notifier_info_ext info = { + .info.dev = dev, + .ext.mtu = arg, + }; + +BUILD_BUG_ON (offsetof(struct netdev_notifier_info_ext , info) !=0 ); + +return call_netdevice_notifiers_info (val, &info.info); +} +#ifdef CONFIG_NET_INGRESS static DEFINE_STATIC_KEY_FALSE (ingress_needed_key);
@@ -7118,14 +7140,16 @@ int dev_set_mtu(struct net_device *dev, err =__dev_set_mtu (dev, new_mtu);if (!err) { - err =call_netdevice_notifiers (NETDEV_CHANGEMTU , dev); + err =call_netdevice_notifiers_mtu (NETDEV_CHANGEMTU , dev, + orig_mtu); err =notifier_to_errno (err);if (err) {/* setting mtu back and notifying everyone again, * so that they have a chance to revert changes. */ __dev_set_mtu (dev, orig_mtu); -call_netdevice_notifiers (NETDEV_CHANGEMTU , dev); +call_netdevice_notifiers_mtu (NETDEV_CHANGEMTU , dev, + new_mtu); } }return err;
net/ipv4/fib_frontend.c +8 -4
@@ -1243,7 +1243,8 @@ static int fib_inetaddr_event(struct notstatic int fib_netdev_event (struct notifier_block *this,unsigned long event,void *ptr) {struct net_device *dev =netdev_notifier_info_to_dev (ptr); -struct netdev_notifier_changeupper_info *info; +struct netdev_notifier_changeupper_info *upper_info = ptr; +struct netdev_notifier_info_ext *info_ext = ptr;struct in_device *in_dev;struct net *net =dev_net (dev);unsigned int flags;
@@ -1278,16 +1279,19 @@ static int fib_netdev_event(struct notiffib_sync_up (dev,RTNH_F_LINKDOWN ); elsefib_sync_down_dev (dev ,event ,false ); -/* fall through */ +rt_cache_flush (net); +break ;case NETDEV_CHANGEMTU : +fib_sync_mtu (dev, info_ext->ext.mtu);rt_cache_flush (net);break ;case NETDEV_CHANGEUPPER : - info = ptr; + upper_info = ptr;/* flush all routes if dev is linked to or unlinked from * an L3 master device (e.g., VRF) */ -if (info->upper_dev &&netif_is_l3_master (info->upper_dev)) +if (upper_info->upper_dev && +netif_is_l3_master (upper_info->upper_dev))fib_disable_ip (dev,NETDEV_DOWN , true);break ; }
net/ipv4/fib_semantics.c +50 -0
56 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 11/135 net/ipv6: Display all addresses in output of /proc/net/if_inet6
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Barnhill <[email protected]>
[ Upstream commit 86f9bd1ff61c413a2a251fa736463295e4e24733 ]
The backend handling for /proc/net/if_inet6 in addrconf.c doesn't properly handle starting/stopping the iteration. The problem is that at some point during the iteration, an overflow is detected and the process is subsequently stopped. The item being shown via seq_printf() when the overflow occurs is not actually shown, though. When start() is subsequently called to resume iterating, it returns the next item, and thus the item that was being processed when the overflow occurred never gets printed.
Alter the meaning of the private data member "offset". Currently, when it is not 0 (which only happens at the very beginning), "offset" represents the next hlist item to be printed. After this change, "offset" always represents the current item.
This is also consistent with the private data member "bucket", which represents the current bucket, and also the use of "pos" as defined in seq_file.txt:
The pos passed to start() will always be either zero, or the most recent pos used in the previous session.
--- net/ipv6/addrconf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
net/ipv6/addrconf.c +1 -3
@@ -4203,7 +4203,6 @@ static struct inet6_ifaddr *if6_get_firs p++;continue ; } - state->offset++;return ifa; }
@@ -4227,13 +4226,12 @@ static struct inet6_ifaddr *if6_get_nextreturn ifa; } + state->offset =0 ;while (++state->bucket <IN6_ADDR_HSIZE ) { - state->offset =0 ;hlist_for_each_entry_rcu (ifa, &inet6_addr_lst[state->bucket], addr_lst) {if (!net_eq (dev_net (ifa->idev->dev), net))continue ; - state->offset++;return ifa; } }
Greg Kroah-Hartman
maintainerPATCH 14/135 net: mvpp2: fix a txq_done race condition
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antoine Tenart <[email protected]>
[ Upstream commit 774268f3e51b53ed432a1ec516574fd5ba469398 ]
When no Tx IRQ is available, the txq_done() routine (called from tx_done()) shouldn't be called from the polling function, as in such case it is already called in the Tx path thanks to an hrtimer. This mostly occurred when using PPv2.1, as the engine then do not have Tx IRQs.
--- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +6 -4
@@ -3056,10 +3056,12 @@ static int mvpp2_poll(struct napi_struct cause_rx_tx & ~MVPP2_CAUSE_MISC_SUM_MASK); } - cause_tx = cause_rx_tx &MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_MASK ; -if (cause_tx) { - cause_tx >>=MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_OFFSET ; -mvpp2_tx_done (port, cause_tx, qv->sw_thread_id); +if (port->has_tx_irqs) { + cause_tx = cause_rx_tx &MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_MASK ; +if (cause_tx) { + cause_tx >>=MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_OFFSET ; +mvpp2_tx_done (port, cause_tx, qv->sw_thread_id); + } }/* Process RX packets */
Greg Kroah-Hartman
maintainerPATCH 15/135 net: sched: Add policy validation for tc attributes
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
[ Upstream commit 8b4c3cdd9dd8290343ce959a132d3b334062c5b9 ]
A number of TC attributes are processed without proper validation (e.g., length checks). Add a tca policy for all input attributes and use when invoking nlmsg_parse.
The 2 Fixes tags below cover the latest additions. The other attributes are a string (KIND), nested attribute (OPTIONS which does seem to have validation in most cases), for dumps only or a flag.
--- net/sched/sch_api.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
net/sched/sch_api.c +20 -4
@@ -1304,6 +1304,18 @@ check_loop_fn(struct Qdisc *q, unsigned* Delete/get qdisc. */ +const struct nla_policy rtm_tca_policy[TCA_MAX +1 ] = { + [TCA_KIND ] = { .type =NLA_STRING }, + [TCA_OPTIONS ] = { .type =NLA_NESTED }, + [TCA_RATE ] = { .type =NLA_BINARY , + .len =sizeof (struct tc_estimator ) }, + [TCA_STAB ] = { .type =NLA_NESTED }, + [TCA_DUMP_INVISIBLE ] = { .type =NLA_FLAG }, + [TCA_CHAIN ] = { .type =NLA_U32 }, + [TCA_INGRESS_BLOCK ] = { .type =NLA_U32 }, + [TCA_EGRESS_BLOCK ] = { .type =NLA_U32 }, +}; +static int tc_get_qdisc (struct sk_buff *skb,struct nlmsghdr *n,struct netlink_ext_ack *extack) {
@@ -1320,7 +1332,8 @@ static int tc_get_qdisc(struct sk_buff * !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))return -EPERM ; - err =nlmsg_parse (n,sizeof (*tcm), tca,TCA_MAX ,NULL , extack); + err =nlmsg_parse (n,sizeof (*tcm), tca,TCA_MAX , rtm_tca_policy, + extack);if (err <0 )return err;
@@ -1404,7 +1417,8 @@ static int tc_modify_qdisc(struct sk_buf replay:/* Reinit, just in case something touches this. */ - err =nlmsg_parse (n,sizeof (*tcm), tca,TCA_MAX ,NULL , extack); + err =nlmsg_parse (n,sizeof (*tcm), tca,TCA_MAX , rtm_tca_policy, + extack);if (err <0 )return err;
@@ -1638,7 +1652,8 @@ static int tc_dump_qdisc(struct sk_buff idx =0 ;ASSERT_RTNL (); - err =nlmsg_parse (nlh,sizeof (struct tcmsg ), tca,TCA_MAX ,NULL ,NULL ); + err =nlmsg_parse (nlh,sizeof (struct tcmsg ), tca,TCA_MAX , + rtm_tca_policy,NULL );if (err <0 )return err;
@@ -1857,7 +1872,8 @@ static int tc_ctl_tclass(struct sk_buff !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))return -EPERM ; - err =nlmsg_parse (n,sizeof (*tcm), tca,TCA_MAX ,NULL , extack); + err =nlmsg_parse (n,sizeof (*tcm), tca,TCA_MAX , rtm_tca_policy, + extack);if (err <0 )return err;
Greg Kroah-Hartman
maintainerPATCH 16/135 net: sched: cls_u32: fix hnode refcounting
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit 6d4c407744dd0338da5d5d76f40dce5adabfb30a ]
cls_u32.c misuses refcounts for struct tc_u_hnode - it counts references via ->hlist and via ->tp_root together. u32_destroy() drops the former and, in case when there had been links, leaves the sucker on the list. As the result, there's nothing to protect it from getting freed once links are dropped.
That also makes the "is it busy" check incapable of catching the root hnode - it *is* busy (there's a reference from tp), but we don't see it as something separate. "Is it our root?" check partially covers that, but the problem exists for others' roots as well.
AFAICS, the minimal fix preserving the existing behaviour (where it doesn't include oopsen, that is) would be this:
* count tp->root and tp_c->hlist as separate references. I.e.
have u32_init() set refcount to 2, not 1.
* in u32_destroy() we always drop the former;
in u32_destroy_hnode() - the latter.
That way we have *all* references contributing to refcount. List
removal happens in u32_destroy_hnode() (called only when ->refcnt is 1) an in u32_destroy() in case of tc_u_common going away, along with everything reachable from it. IOW, that way we know that u32_destroy_key() won't free something still on the list (or pointed to by someone's ->root).
Reproducer:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 100 handle 1: \
u32 divisor 1
tc filter add dev eth0 parent ffff: protocol ip prio 200 handle 2: \
u32 divisor 1
tc filter add dev eth0 parent ffff: protocol ip prio 100 \
handle 1:0:11 u32 ht 1: link 801: offset at 0 mask 0f00 shift 6 \
plus 0 eat match ip protocol 6 ff
tc filter delete dev eth0 parent ffff: protocol ip prio 200 tc filter change dev eth0 parent ffff: protocol ip prio 100 \
handle 1:0:11 u32 ht 1: link 0: offset at 0 mask 0f00 shift 6 plus 0 \
eat match ip protocol 6 ff
tc filter delete dev eth0 parent ffff: protocol ip prio 100
--- net/sched/cls_u32.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
net/sched/cls_u32.c +5 -5
@@ -397,6 +397,7 @@ static int u32_init(struct tcf_proto *tprcu_assign_pointer (tp_c->hlist, root_ht); root_ht->tp_c = tp_c; + root_ht->refcnt++;rcu_assign_pointer (tp->root, root_ht); tp->data = tp_c;return 0 ;
@@ -608,7 +609,7 @@ static int u32_destroy_hnode(struct tcf_struct tc_u_hnode __rcu **hn;struct tc_u_hnode *phn; -WARN_ON (ht->refcnt); +WARN_ON (--ht->refcnt);u32_clear_hnode (tp, ht, extack);
@@ -647,7 +648,7 @@ static void u32_destroy(struct tcf_protoWARN_ON (root_ht ==NULL ); -if (root_ht && --root_ht->refcnt ==0 ) +if (root_ht && --root_ht->refcnt ==1 )u32_destroy_hnode (tp, root_ht, extack);if (--tp_c->refcnt ==0 ) {
@@ -696,7 +697,6 @@ static int u32_delete(struct tcf_proto * }if (ht->refcnt ==1 ) { - ht->refcnt--;u32_destroy_hnode (tp, ht, extack); }else {NL_SET_ERR_MSG_MOD (extack,"Can not delete in-use filter" );
@@ -706,11 +706,11 @@ static int u32_delete(struct tcf_proto * out: *last = true;if (root_ht) { -if (root_ht->refcnt >1 ) { +if (root_ht->refcnt >2 ) { *last = false; goto ret; } -if (root_ht->refcnt ==1 ) { +if (root_ht->refcnt ==2 ) {if (!ht_empty (root_ht)) { *last = false; goto ret;
Greg Kroah-Hartman
maintainerPATCH 18/135 net/usb: cancel pending work when unbinding smsc75xx
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Zhao <[email protected]>
[ Upstream commit f7b2a56e1f3dcbdb4cf09b2b63e859ffe0e09df8 ]
Cancel pending work before freeing smsc75xx private data structure during binding. This fixes the following crash in the driver:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: mutex_lock+0x2b/0x3f <snipped> Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx] task: ffff8caa83e85700 task.stack: ffff948b80518000 RIP: 0010:mutex_lock+0x2b/0x3f <snipped> Call Trace: smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx] process_one_work+0x18d/0x2fc worker_thread+0x1a2/0x269 ? pr_cont_work+0x58/0x58 kthread+0xfa/0x10a ? pr_cont_work+0x58/0x58 ? rcu_read_unlock_sched_notrace+0x48/0x48 ret_from_fork+0x22/0x40
--- drivers/net/usb/smsc75xx.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/usb/smsc75xx.c +1 -0
@@ -1517,6 +1517,7 @@ static void smsc75xx_unbind(struct usbne {struct smsc75xx_priv *pdata = (struct smsc75xx_priv *)(dev->data[0 ]);if (pdata) { +cancel_work_sync (&pdata->set_multicast);netif_dbg (dev, ifdown, dev->net,"free pdata\n" );kfree (pdata); pdata =NULL ;
Greg Kroah-Hartman
maintainerPATCH 2/135 bnxt_en: free hwrm resources, if driver probe fails.
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Venkat Duvvuru <[email protected]>
[ Upstream commit a2bf74f4e1b82395dad2b08d2a911d9151db71c1 ]
When the driver probe fails, all the resources that were allocated prior to the failure must be freed. However, hwrm dma response memory is not getting freed.
This patch fixes the problem described above.
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +6 -4
@@ -3015,10 +3015,11 @@ static void bnxt_free_hwrm_resources(str {struct pci_dev *pdev = bp->pdev; -dma_free_coherent (&pdev->dev,PAGE_SIZE , bp->hwrm_cmd_resp_addr, - bp->hwrm_cmd_resp_dma_addr); - - bp->hwrm_cmd_resp_addr =NULL ; +if (bp->hwrm_cmd_resp_addr) { +dma_free_coherent (&pdev->dev,PAGE_SIZE , bp->hwrm_cmd_resp_addr, + bp->hwrm_cmd_resp_dma_addr); + bp->hwrm_cmd_resp_addr =NULL ; + }if (bp->hwrm_dbg_resp_addr) { dma_free_coherent(&pdev->dev, HWRM_DBG_REG_BUF_SIZE, bp->hwrm_dbg_resp_addr,
@@ -8931,6 +8932,7 @@ init_err_cleanup_tc:bnxt_clear_int_mode (bp); init_err_pci_clean: +bnxt_free_hwrm_resources (bp);bnxt_cleanup_pci (bp); init_err_free:
Greg Kroah-Hartman
maintainerPATCH 21/135 rtnetlink: fix rtnl_fdb_dump() for ndmsg header
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauricio Faria de Oliveira <[email protected]>
[ Upstream commit bd961c9bc66497f0c63f4ba1d02900bb85078366 ]
Currently, rtnl_fdb_dump() assumes the family header is 'struct ifinfomsg', which is not always true -- 'struct ndmsg' is used by iproute2 ('ip neigh').
The problem is, the function bails out early if nlmsg_parse() fails, which does occur for iproute2 usage of 'struct ndmsg' because the payload length is shorter than the family header alone (as 'struct ifinfomsg' is assumed).
This breaks backward compatibility with userspace -- nothing is sent back.
Some examples with iproute2 and netlink library for go [1]:
1) $ bridge fdb show
33:33:00:00:00:01 dev ens3 self permanent
01:00:5e:00:00:01 dev ens3 self permanent
33:33:ff:15:98:30 dev ens3 self permanent
This one works, as it uses 'struct ifinfomsg'.
fdb_show() @ iproute2/bridge/fdb.c
"""
.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)),
...
if (rtnl_dump_request(&rth, RTM_GETNEIGH, [...]
""" 2) $ ip --family bridge neigh
RTNETLINK answers: Invalid argument
Dump terminated
This one fails, as it uses 'struct ndmsg'.
do_show_or_flush() @ iproute2/ip/ipneigh.c
"""
.n.nlmsg_type = RTM_GETNEIGH, .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ndmsg)), """
3) $ ./neighlist
< no output >
This one fails, as it uses 'struct ndmsg'-based.
neighList() @ netlink/neigh_linux.go
"""
req := h.newNetlinkRequest(unix.RTM_GETNEIGH, [...] msg := Ndmsg{
"""
The actual breakage was introduced by commit 0ff50e83b512 ("net: rtnetlink:
bail out from rtnl_fdb_dump() on parse error"), because nlmsg_parse() fails if the payload length (with the _actual_ family header) is less than the family header length alone (which is assumed, in parameter 'hdrlen'). This is true in the examples above with struct ndmsg, with size and payload length shorter than struct ifinfomsg.
However, that commit just intends to fix something under the assumption the family header is indeed an 'struct ifinfomsg' - by preventing access to the payload as such (via 'ifm' pointer) if the payload length is not sufficient to actually contain it.
The assumption was introduced by commit 5e6d24358799 ("bridge: netlink dump interface at par with brctl"), to support iproute2's 'bridge fdb' command (not 'ip neigh') which indeed uses 'struct ifinfomsg', thus is not broken.
So, in order to unbreak the 'struct ndmsg' family headers and still allow 'struct ifinfomsg' to continue to work, check for the known message sizes used with 'struct ndmsg' in iproute2 (with zero or one attribute which is not used in this function anyway) then do not parse the data as ifinfomsg.
Same examples with this patch applied (or revert/before the original fix):
$ bridge fdb show
33:33:00:00:00:01 dev ens3 self permanent
01:00:5e:00:00:01 dev ens3 self permanent
33:33:ff:15:98:30 dev ens3 self permanent $ ip --family bridge neigh
dev ens3 lladdr 33:33:00:00:00:01 PERMANENT
dev ens3 lladdr 01:00:5e:00:00:01 PERMANENT
dev ens3 lladdr 33:33:ff:15:98:30 PERMANENT $ ./neighlist
netlink.Neigh{LinkIndex:2, Family:7, State:128, Type:0, Flags:2, IP:net.IP(nil), HardwareAddr:net.HardwareAddr{0x33, 0x33, 0x0, 0x0, 0x0, 0x1}, LLIPAddr:net.IP(nil), Vlan:0, VNI:0}
netlink.Neigh{LinkIndex:2, Family:7, State:128, Type:0, Flags:2, IP:net.IP(nil), HardwareAddr:net.HardwareAddr{0x1, 0x0, 0x5e, 0x0, 0x0, 0x1}, LLIPAddr:net.IP(nil), Vlan:0, VNI:0}
netlink.Neigh{LinkIndex:2, Family:7, State:128, Type:0, Flags:2, IP:net.IP(nil), HardwareAddr:net.HardwareAddr{0x33, 0x33, 0xff, 0x15, 0x98, 0x30}, LLIPAddr:net.IP(nil), Vlan:0, VNI:0}Tested on mainline (v4.19-rc6) and net-next (3bd09b05b068).
References:
[1] netlink library for go (test-case)
https://github.com/vishvananda/netlink
$ cat ~/go/src/neighlist/main.go
package main
import ("fmt"; "syscall"; "github.com/vishvananda/netlink") func main() {
neighs, _ := netlink.NeighList(0, syscall.AF_BRIDGE) for _, neigh := range neighs { fmt.Printf("%#v\n", neigh) }
}
$ export GOPATH=~/go
$ go get github.com/vishvananda/netlink
$ go build neighlist
$ ~/go/src/neighlist/neighlist
Thanks to David Ahern for suggestions to improve this patch.
--- net/core/rtnetlink.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)
net/core/rtnetlink.c +20 -9
@@ -3694,16 +3694,27 @@ static int rtnl_fdb_dump(struct sk_buffint err =0 ;int fidx =0 ; - err =nlmsg_parse (cb->nlh,sizeof (struct ifinfomsg ), tb, -IFLA_MAX , ifla_policy,NULL ); -if (err <0 ) { -return -EINVAL ; - }else if (err ==0 ) { -if (tb[IFLA_MASTER ]) - br_idx =nla_get_u32 (tb[IFLA_MASTER ]); - } +/* A hack to preserve kernel<->userspace interface. +* Before Linux v4.12 this code accepted ndmsg since iproute2 v3.3.0. +* However, ndmsg is shorter than ifinfomsg thus nlmsg_parse() bails. +* So, check for ndmsg with an optional u32 attribute (not used here). +* Fortunately these sizes don't conflict with the size of ifinfomsg +* with an optional attribute. +*/ +if (nlmsg_len (cb->nlh) !=sizeof (struct ndmsg ) && + (nlmsg_len (cb->nlh) !=sizeof (struct ndmsg ) + +nla_attr_size (sizeof (u32)))) { + err =nlmsg_parse (cb->nlh,sizeof (struct ifinfomsg ), tb, +IFLA_MAX , ifla_policy,NULL ); +if (err <0 ) { +return -EINVAL ; + }else if (err ==0 ) { +if (tb[IFLA_MASTER ]) + br_idx =nla_get_u32 (tb[IFLA_MASTER ]); + } - brport_idx = ifm->ifi_index; + brport_idx = ifm->ifi_index; + }if (br_idx) { br_dev =__dev_get_by_index (net, br_idx);
Greg Kroah-Hartman
maintainerPATCH 23/135 sctp: update dst pmtu with the correct daddr
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit d7ab5cdce54da631f0c8c11e506c974536a3581e ]
When processing pmtu update from an icmp packet, it calls .update_pmtu with sk instead of skb in sctp_transport_update_pmtu.
However for sctp, the daddr in the transport might be different from inet_sock->inet_daddr or sk->sk_v6_daddr, which is used to update or create the route cache. The incorrect daddr will cause a different route cache created for the path.
So before calling .update_pmtu, inet_sock->inet_daddr/sk->sk_v6_daddr should be updated with the daddr in the transport, and update it back after it's done.
The issue has existed since route exceptions introduction.
--- net/sctp/transport.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
net/sctp/transport.c +10 -2
@@ -260,6 +260,7 @@ void sctp_transport_pmtu(struct sctp_trabool sctp_transport_update_pmtu (struct sctp_transport *t,u32 pmtu) {struct dst_entry *dst =sctp_transport_dst_check (t); +struct sock *sk = t->asoc->base.sk;bool change = true;if (unlikely (pmtu <SCTP_DEFAULT_MINSEGMENT )) {
@@ -271,12 +272,19 @@ bool sctp_transport_update_pmtu(struct s pmtu =SCTP_TRUNC4 (pmtu);if (dst) { - dst->ops->update_pmtu (dst, t->asoc->base.sk,NULL , pmtu); +struct sctp_pf *pf =sctp_get_pf_specific (dst->ops->family); +union sctp_addr addr; + + pf->af->from_sk (&addr, sk); + pf->to_sk_daddr (&t->ipaddr, sk); + dst->ops->update_pmtu (dst, sk,NULL , pmtu); + pf->to_sk_daddr (&addr, sk); + dst =sctp_transport_dst_check (t); }if (!dst) { - t->af_specific->get_dst (t, &t->saddr, &t->fl, t->asoc->base.sk); + t->af_specific->get_dst (t, &t->saddr, &t->fl, sk); dst = t->dst; }
Greg Kroah-Hartman
maintainerPATCH 24/135 team: Forbid enslaving team device to itself
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 471b83bd8bbe4e89743683ef8ecb78f7029d8288 ]
team's ndo_add_slave() acquires 'team->lock' and later tries to open the newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event that causes the VLAN driver to add VLAN 0 on the team device. team's ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and deadlock.
Fix this by checking early at the enslavement function that a team device is not being enslaved to itself.
A similar check was added to the bond driver in commit 09a89c219baf ("bonding: disallow enslaving a bond to itself").
WARNING: possible recursive locking detected
4.18.0-rc7+ #176 Not tainted
--------------------------------------------
syz-executor4/6391 is trying to acquire lock:
(____ptrval____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
but task is already holding lock:
(____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
---- lock(&team->lock);
lock(&team->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by syz-executor4/6391:
#0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline] #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4662 #1: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
stack backtrace: CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_deadlock_bug kernel/locking/lockdep.c:1765 [inline] check_deadlock kernel/locking/lockdep.c:1809 [inline] validate_chain kernel/locking/lockdep.c:2405 [inline] __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435 lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 __mutex_lock_common kernel/locking/mutex.c:757 [inline] __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909 team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868 vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210 __vlan_vid_add net/8021q/vlan_core.c:278 [inline] vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308 vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381 notifier_call_chain+0x180/0x390 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735 call_netdevice_notifiers net/core/dev.c:1753 [inline] dev_open+0x173/0x1b0 net/core/dev.c:1433 team_port_add drivers/net/team/team.c:1219 [inline] team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948 do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248 do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382 rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636 rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:642 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:652 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126 __sys_sendmsg+0x11d/0x290 net/socket.c:2164 __do_sys_sendmsg net/socket.c:2173 [inline] __se_sys_sendmsg net/socket.c:2171 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x456b29 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29 RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004 RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000
--- drivers/net/team/team.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/team/team.c +6 -0
@@ -1172,6 +1172,12 @@ static int team_port_add(struct team *tereturn -EBUSY ; } +if (dev == port_dev) { +NL_SET_ERR_MSG (extack,"Cannot enslave team device to itself" ); +netdev_err (dev,"Cannot enslave team device to itself\n" ); +return -EINVAL ; + } +if (port_dev->features &NETIF_F_VLAN_CHALLENGED &&vlan_uses_dev (dev)) {NL_SET_ERR_MSG (extack,"Device is VLAN challenged and team device has VLAN set up" );
Greg Kroah-Hartman
maintainerPATCH 25/135 tipc: fix flow control accounting for implicit connect
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Parthasarathy Bhuvaragan <[email protected]>
[ Upstream commit 92ef12b32feab8f277b69e9fb89ede2796777f4d ]
In the case of implicit connect message with data > 1K, the flow control accounting is incorrect. At this state, the socket does not know the peer nodes capability and falls back to legacy flow control by return 1, however the receiver of this message will perform the new block accounting. This leads to a slack and eventually traffic disturbance.
In this commit, we perform tipc_node_get_capabilities() at implicit connect and perform accounting based on the peer's capability.
--- net/tipc/socket.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/tipc/socket.c +3 -1
@@ -1422,8 +1422,10 @@ static int __tipc_sendstream(struct sock/* Handle implicit connection setup */ if (unlikely (dest)) { rc =__tipc_sendmsg (sock, m, dlen); -if (dlen && (dlen == rc)) +if (dlen && dlen == rc) { + tsk->peer_caps =tipc_node_get_capabilities (net, dnode); tsk->snt_unacked =tsk_inc (tsk, dlen +msg_hdr_sz (hdr)); + }return rc; }
Greg Kroah-Hartman
maintainerPATCH 26/135 udp: Unbreak modules that rely on external __skb_recv_udp() availability
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Kosina <[email protected]>
[ Upstream commit 7e823644b60555f70f241274b8d0120dd919269a ]
Commit 2276f58ac589 ("udp: use a separate rx queue for packet reception") turned static inline __skb_recv_udp() from being a trivial helper around __skb_recv_datagram() into a UDP specific implementaion, making it EXPORT_SYMBOL_GPL() at the same time.
There are external modules that got broken by __skb_recv_udp() not being visible to them. Let's unbreak them by making __skb_recv_udp EXPORT_SYMBOL().
Rationale (one of those) why this is actually "technically correct" thing to do: __skb_recv_udp() used to be an inline wrapper around __skb_recv_datagram(), which itself (still, and correctly so, I believe) is EXPORT_SYMBOL().
--- net/ipv4/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/udp.c +1 -1
@@ -1631,7 +1631,7 @@ busy_check: *err = error;return NULL ; } -EXPORT_SYMBOL_GPL (__skb_recv_udp); +EXPORT_SYMBOL (__skb_recv_udp);/* * This should be easy, if there is something there we
Greg Kroah-Hartman
maintainerPATCH 27/135 net: qualcomm: rmnet: Skip processing loopback packets
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Tranchetti <[email protected]>
[ Upstream commit a07f388e2cde2be74b263f85df6f672fea0305a1 ]
RMNET RX handler was processing invalid packets that were originally sent on the real device and were looped back via dev_loopback_xmit(). This was detected using syzkaller.
--- drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +3 -0
@@ -189,6 +189,9 @@ rx_handler_result_t rmnet_rx_handler(strif (!skb) goto done; +if (skb->pkt_type ==PACKET_LOOPBACK ) +return RX_HANDLER_PASS ; + dev = skb->dev; port =rmnet_get_port (dev);
Greg Kroah-Hartman
maintainerPATCH 28/135 net: qualcomm: rmnet: Fix incorrect allocation flag in transmit
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Subash Abhinov Kasiviswanathan <[email protected]>
[ Upstream commit 6392ff3c8e4c23d0a09b0ae9f94feb3effed490b ]
The incoming skb needs to be reallocated in case the headroom is not sufficient to add the MAP header. This allocation needs to be atomic otherwise it results in the following splat
[32805.801456] BUG: sleeping function called from invalid context [32805.841141] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [32805.904773] task: ffffffd7c5f62280 task.stack: ffffff80464a8000 [32805.910851] pc : ___might_sleep+0x180/0x188 [32805.915143] lr : ___might_sleep+0x180/0x188 [32806.131520] Call trace: [32806.134041] ___might_sleep+0x180/0x188 [32806.137980] __might_sleep+0x50/0x84 [32806.141653] __kmalloc_track_caller+0x80/0x3bc [32806.146215] __kmalloc_reserve+0x3c/0x88 [32806.150241] pskb_expand_head+0x74/0x288 [32806.154269] rmnet_egress_handler+0xb0/0x1d8 [32806.162239] rmnet_vnd_start_xmit+0xc8/0x13c [32806.166627] dev_hard_start_xmit+0x148/0x280 [32806.181181] sch_direct_xmit+0xa4/0x198 [32806.185125] __qdisc_run+0x1f8/0x310 [32806.188803] net_tx_action+0x23c/0x26c [32806.192655] __do_softirq+0x220/0x408 [32806.196420] do_softirq+0x4c/0x70
--- drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +1 -1
@@ -147,7 +147,7 @@ static int rmnet_map_egress_handler(stru }if (skb_headroom (skb) < required_headroom) { -if (pskb_expand_head (skb, required_headroom,0 ,GFP_KERNEL )) +if (pskb_expand_head (skb, required_headroom,0 ,GFP_ATOMIC ))return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 29/135 net: qualcomm: rmnet: Fix incorrect allocation flag in receive path
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Subash Abhinov Kasiviswanathan <[email protected]>
[ Upstream commit ec405641e2b73160e26ef17580d0cf28565d146c ]
The incoming skb needs to be reallocated in case the headroom is not sufficient to adjust the ethernet header. This allocation needs to be atomic otherwise it results in this splat
[<600601bb>] ___might_sleep+0x185/0x1a3 [<603f6314>] ? _raw_spin_unlock_irqrestore+0x0/0x27 [<60069bb0>] ? __wake_up_common_lock+0x95/0xd1 [<600602b0>] __might_sleep+0xd7/0xe2 [<60065598>] ? enqueue_task_fair+0x112/0x209 [<600eea13>] __kmalloc_track_caller+0x5d/0x124 [<600ee9b6>] ? __kmalloc_track_caller+0x0/0x124 [<602696d5>] __kmalloc_reserve.isra.34+0x30/0x7e [<603f629b>] ? _raw_spin_lock_irqsave+0x0/0x3d [<6026b744>] pskb_expand_head+0xbf/0x310 [<6025ca6a>] rmnet_rx_handler+0x7e/0x16b [<6025c9ec>] ? rmnet_rx_handler+0x0/0x16b [<6027ad0c>] __netif_receive_skb_core+0x301/0x96f [<60033c17>] ? set_signals+0x0/0x40 [<6027bbcb>] __netif_receive_skb+0x24/0x8e
--- drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +1 -1
@@ -113,7 +113,7 @@ rmnet_map_ingress_handler(struct sk_buffstruct sk_buff *skbn;if (skb->dev->type ==ARPHRD_ETHER ) { -if (pskb_expand_head (skb,ETH_HLEN ,0 ,GFP_KERNEL )) { +if (pskb_expand_head (skb,ETH_HLEN ,0 ,GFP_ATOMIC )) {kfree_skb (skb);return ; }
Greg Kroah-Hartman
maintainerPATCH 3/135 bonding: avoid possible dead-lock
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Bandewar <[email protected]>
[ Upstream commit d4859d749aa7090ffb743d15648adb962a1baeae ]
Syzkaller reported this on a slightly older kernel but it's still applicable to the current kernel -
======================================================
WARNING: possible circular locking dependency detected
4.18.0-next-20180823+ #46 Not tainted
------------------------------------------------------
syz-executor4/26841 is trying to acquire lock:00000000dd41ef48 ((wq_completion)bond_dev->name){+.+.}, at: flush_workqueue+0x2db/0x1e10 kernel/workqueue.c:2652
but task is already holding lock:00000000768ab431 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline] 00000000768ab431 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4708
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (rtnl_mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
bond_netdev_notify drivers/net/bonding/bond_main.c:1310 [inline]
bond_netdev_notify_work+0x44/0xd0 drivers/net/bonding/bond_main.c:1320
process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415-> #1 ((work_completion)(&(&nnw->work)->work)){+.+.}:
process_one_work+0xc0b/0x1aa0 kernel/workqueue.c:2129
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415-> #0 ((wq_completion)bond_dev->name){+.+.}:
lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
__alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
register_netdevice+0x337/0x1100 net/core/dev.c:8410
bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:622 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:632
___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
__sys_sendmsg+0x11d/0x290 net/socket.c:2153
__do_sys_sendmsg net/socket.c:2162 [inline]
__se_sys_sendmsg net/socket.c:2160 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbeother info that might help us debug this:
Chain exists of: (wq_completion)bond_dev->name --> (work_completion)(&(&nnw->work)->work) --> rtnl_mutex Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rtnl_mutex);
lock((work_completion)(&(&nnw->work)->work));
lock(rtnl_mutex);lock((wq_completion)bond_dev->name);
*** DEADLOCK ***
1 lock held by syz-executor4/26841:
stack backtrace: CPU: 1 PID: 26841 Comm: syz-executor4 Not tainted 4.18.0-next-20180823+ #46 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_circular_bug.isra.34.cold.55+0x1bd/0x27d kernel/locking/lockdep.c:1222 check_prev_add kernel/locking/lockdep.c:1862 [inline] check_prevs_add kernel/locking/lockdep.c:1975 [inline] validate_chain kernel/locking/lockdep.c:2416 [inline] __lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3412 lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901 flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655 drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820 destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155 __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138 bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734 register_netdevice+0x337/0x1100 net/core/dev.c:8410 bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453 rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099 rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:622 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:632 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115 __sys_sendmsg+0x11d/0x290 net/socket.c:2153 __do_sys_sendmsg net/socket.c:2162 [inline] __se_sys_sendmsg net/socket.c:2160 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f2df20a5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2df20a66d4 RCX: 0000000000457089 RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003 RBP: 0000000000930140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000004d40b8 R14: 00000000004c8ad8 R15: 0000000000000001
--- drivers/net/bonding/bond_main.c | 43 +++++++++++++++------------------------- include/net/bonding.h | 7 ------ 2 files changed, 18 insertions(+), 32 deletions(-)
drivers/net/bonding/bond_main.c +17 -26
@@ -210,6 +210,7 @@ static void bond_get_stats(struct net_destatic void bond_slave_arr_handler (struct work_struct *work);static bool bond_time_in_interval (struct bonding *bond,unsigned long last_act,int mod); +static void bond_netdev_notify_work (struct work_struct *work);/*---------------------------- General routines -----------------------------*/
@@ -1276,6 +1277,8 @@ static struct slave *bond_alloc_slave(streturn NULL ; } } +INIT_DELAYED_WORK (&slave->notify_work, bond_netdev_notify_work); +return slave; }
@@ -1283,6 +1286,7 @@ static void bond_free_slave(struct slave {struct bonding *bond =bond_get_bond_by_slave (slave); +cancel_delayed_work_sync (&slave->notify_work);if (BOND_MODE (bond) ==BOND_MODE_8023AD )kfree (SLAVE_AD_INFO (slave));
@@ -1304,39 +1308,26 @@ static void bond_fill_ifslave(struct sla info->link_failure_count = slave->link_failure_count; } -static void bond_netdev_notify (struct net_device *dev, -struct netdev_bonding_info *info) -{ -rtnl_lock (); -netdev_bonding_info_change (dev, info); -rtnl_unlock (); -} -static void bond_netdev_notify_work (struct work_struct *_work) { -struct netdev_notify_work *w = - container_of(_work, struct netdev_notify_work, work.work); + struct slave *slave = container_of(_work, struct slave, + notify_work.work); + +if (rtnl_trylock ()) { +struct netdev_bonding_info binfo; -bond_netdev_notify (w->dev, &w->bonding_info); -dev_put (w->dev); -kfree (w); +bond_fill_ifslave (slave, &binfo.slave); +bond_fill_ifbond (slave->bond, &binfo.master); +netdev_bonding_info_change (slave->dev, &binfo); +rtnl_unlock (); + }else { +queue_delayed_work (slave->bond->wq, &slave->notify_work,1 ); + } }void bond_queue_slave_event (struct slave *slave) { -struct bonding *bond = slave->bond; -struct netdev_notify_work *nnw =kzalloc (sizeof (*nnw),GFP_ATOMIC ); - -if (!nnw) -return ; - -dev_hold (slave->dev); - nnw->dev = slave->dev; -bond_fill_ifslave (slave, &nnw->bonding_info.slave); -bond_fill_ifbond (bond, &nnw->bonding_info.master); -INIT_DELAYED_WORK (&nnw->work, bond_netdev_notify_work); - -queue_delayed_work (slave->bond->wq, &nnw->work,0 ); +queue_delayed_work (slave->bond->wq, &slave->notify_work,0 ); }void bond_lower_state_changed (struct slave *slave)
include/net/bonding.h +1 -6
@@ -139,12 +139,6 @@ struct bond_parm_tbl {int mode; }; -struct netdev_notify_work { -struct delayed_work work; -struct net_device *dev; -struct netdev_bonding_info bonding_info; -}; -struct slave {struct net_device *dev;/* first - useful for panic debug */ struct bonding *bond;/* our master */
@@ -172,6 +166,7 @@ struct slave {#ifdef CONFIG_NET_POLL_CONTROLLER struct netpoll *np;#endif +struct delayed_work notify_work;struct kobject kobj;struct rtnl_link_stats64 slave_stats; };
Greg Kroah-Hartman
maintainerPATCH 30/135 tun: remove unused parameters
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 06e55addd3f40b5294e448c2cb7605ca4f28c2e3 ]
tun_napi_disable() and tun_napi_del() do not need a pointer to the tun_struct
--- drivers/net/tun.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/net/tun.c +6 -6
@@ -323,13 +323,13 @@ static void tun_napi_init(struct tun_str } } -static void tun_napi_disable (struct tun_struct *tun,struct tun_file *tfile) +static void tun_napi_disable (struct tun_file *tfile) {if (tfile->napi_enabled)napi_disable (&tfile->napi); } -static void tun_napi_del (struct tun_struct *tun,struct tun_file *tfile) +static void tun_napi_del (struct tun_file *tfile) {if (tfile->napi_enabled)netif_napi_del (&tfile->napi);
@@ -688,8 +688,8 @@ static void __tun_detach(struct tun_file tun =rtnl_dereference (tfile->tun);if (tun && clean) { -tun_napi_disable (tun, tfile); -tun_napi_del (tun, tfile); +tun_napi_disable (tfile); +tun_napi_del (tfile); }if (tun && !tfile->detached) {
@@ -756,7 +756,7 @@ static void tun_detach_all(struct net_defor (i =0 ; i < n; i++) { tfile =rtnl_dereference (tun->tfiles[i]);BUG_ON (!tfile); -tun_napi_disable (tun, tfile); +tun_napi_disable (tfile); tfile->socket.sk->sk_shutdown =RCV_SHUTDOWN ; tfile->socket.sk->sk_data_ready (tfile->socket.sk);RCU_INIT_POINTER (tfile->tun,NULL );
@@ -772,7 +772,7 @@ static void tun_detach_all(struct net_desynchronize_net ();for (i =0 ; i < n; i++) { tfile =rtnl_dereference (tun->tfiles[i]); -tun_napi_del (tun, tfile); +tun_napi_del (tfile);/* Drop read queue */ tun_queue_purge (tfile);xdp_rxq_info_unreg (&tfile->xdp_rxq);
Greg Kroah-Hartman
maintainerPATCH 31/135 tun: initialize napi_mutex unconditionally
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit c7256f579f8302ce2c038181c30060d0b40017b2 ]
This is the first part to fix following syzbot report :
console output: https://syzkaller.appspot.com/x/log.txt?x=145378e6400000 kernel config: https://syzkaller.appspot.com/x/.config?x=443816db871edd66 dashboard link: https://syzkaller.appspot.com/bug?extid=e662df0ac1d753b57e80
Following patch is fixing the race condition, but it seems safer to initialize this mutex at tfile creation anyway.
--- drivers/net/tun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/tun.c +1 -1
@@ -319,7 +319,6 @@ static void tun_napi_init(struct tun_strnetif_napi_add (tun->dev, &tfile->napi, tun_napi_poll,NAPI_POLL_WEIGHT );napi_enable (&tfile->napi); -mutex_init (&tfile->napi_mutex); } }
@@ -3241,6 +3240,7 @@ static int tun_chr_open(struct inode *inreturn -ENOMEM ; } +mutex_init (&tfile->napi_mutex);RCU_INIT_POINTER (tfile->tun,NULL ); tfile->flags =0 ; tfile->ifindex =0 ;
Greg Kroah-Hartman
maintainerPATCH 32/135 tun: napi flags belong to tfile
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit af3fb24eecb2c59246e03c99386037fd5ad84ffd ]
Since tun->flags might be shared by multiple tfile structures, it is better to make sure tun_get_user() is using the flags for the current tfile.
Presence of the READ_ONCE() in tun_napi_frags_enabled() gave a hint of what could happen, but we need something stronger to please syzbot.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 13647 Comm: syz-executor5 Not tainted 4.19.0-rc5+ #59 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dev_gro_receive+0x132/0x2720 net/core/dev.c:5427 Code: 48 c1 ea 03 80 3c 02 00 0f 85 6e 20 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 6e 10 49 8d bd d0 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 59 20 00 00 4d 8b a5 d0 00 00 00 31 ff 41 81 e4 RSP: 0018:ffff8801c400f410 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8618d325 RDX: 000000000000001a RSI: ffffffff86189f97 RDI: 00000000000000d0 RBP: ffff8801c400f608 R08: ffff8801c8fb4300 R09: 0000000000000000 R10: ffffed0038801ed7 R11: 0000000000000003 R12: ffff8801d327d358 R13: 0000000000000000 R14: ffff8801c16dd8c0 R15: 0000000000000004 FS: 00007fe003615700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f3c43db8 CR3: 00000001bebb2000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: napi_gro_frags+0x3f4/0xc90 net/core/dev.c:5715 tun_get_user+0x31d5/0x42a0 drivers/net/tun.c:1922 tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:1967 call_write_iter include/linux/fs.h:1808 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6b8/0x9f0 fs/read_write.c:487 vfs_write+0x1fc/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457579 Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fe003614c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579 RDX: 0000000000000012 RSI: 0000000020000000 RDI: 000000000000000a RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe0036156d4 R13: 00000000004c5574 R14: 00000000004d8e98 R15: 00000000ffffffff Modules linked in: RIP: 0010:dev_gro_receive+0x132/0x2720 net/core/dev.c:5427 Code: 48 c1 ea 03 80 3c 02 00 0f 85 6e 20 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 6e 10 49 8d bd d0 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 59 20 00 00 4d 8b a5 d0 00 00 00 31 ff 41 81 e4 RSP: 0018:ffff8801c400f410 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8618d325 RDX: 000000000000001a RSI: ffffffff86189f97 RDI: 00000000000000d0 RBP: ffff8801c400f608 R08: ffff8801c8fb4300 R09: 0000000000000000 R10: ffffed0038801ed7 R11: 0000000000000003 R12: ffff8801d327d358 R13: 0000000000000000 R14: ffff8801c16dd8c0 R15: 0000000000000004 FS: 00007fe003615700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f3c43db8 CR3: 00000001bebb2000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
--- drivers/net/tun.c | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-)
drivers/net/tun.c +16 -13
@@ -181,6 +181,7 @@ struct tun_file { };struct napi_struct napi;bool napi_enabled; +bool napi_frags_enabled;struct mutex napi_mutex;/* Protects access to the above napi */ struct list_head next;struct tun_struct *detached;
@@ -312,9 +313,10 @@ static int tun_napi_poll(struct napi_str }static void tun_napi_init (struct tun_struct *tun,struct tun_file *tfile, -bool napi_en) +bool napi_en,bool napi_frags) { tfile->napi_enabled = napi_en; + tfile->napi_frags_enabled = napi_en && napi_frags;if (napi_en) {netif_napi_add (tun->dev, &tfile->napi, tun_napi_poll,NAPI_POLL_WEIGHT );
@@ -334,9 +336,9 @@ static void tun_napi_del(struct tun_filenetif_napi_del (&tfile->napi); } -static bool tun_napi_frags_enabled (const struct tun_struct *tun) +static bool tun_napi_frags_enabled (const struct tun_file *tfile) { -return READ_ONCE (tun->flags) &IFF_NAPI_FRAGS ; +return tfile->napi_frags_enabled; }#ifdef CONFIG_TUN_VNET_CROSS_LE
@@ -790,7 +792,7 @@ static void tun_detach_all(struct net_de }static int tun_attach (struct tun_struct *tun,struct file *file, -bool skip_filter,bool napi) +bool skip_filter,bool napi,bool napi_frags) {struct tun_file *tfile = file->private_data;struct net_device *dev = tun->dev;
@@ -863,7 +865,7 @@ static int tun_attach(struct tun_structtun_enable_queue (tfile); }else {sock_hold (&tfile->sk); -tun_napi_init (tun, tfile, napi); +tun_napi_init (tun, tfile, napi, napi_frags); }tun_set_real_num_queues (tun);
@@ -1173,13 +1175,11 @@ static void tun_poll_controller(struct nstruct tun_file *tfile;int i; -if (tun_napi_frags_enabled (tun)) -return ; -rcu_read_lock ();for (i =0 ; i < tun->numqueues; i++) { tfile =rcu_dereference (tun->tfiles[i]); -if (tfile->napi_enabled) +if (!tun_napi_frags_enabled (tfile) && + tfile->napi_enabled)napi_schedule (&tfile->napi); }rcu_read_unlock ();
@@ -1750,7 +1750,7 @@ static ssize_t tun_get_user(struct tun_sint err;u32 rxhash =0 ;int skb_xdp =1 ; -bool frags =tun_napi_frags_enabled (tun); +bool frags =tun_napi_frags_enabled (tfile);if (!(tun->dev->flags &IFF_UP ))return -EIO ;
@@ -2575,7 +2575,8 @@ static int tun_set_iff(struct net *net,return err; err =tun_attach (tun, file, ifr->ifr_flags &IFF_NOFILTER , - ifr->ifr_flags &IFF_NAPI ); + ifr->ifr_flags &IFF_NAPI , + ifr->ifr_flags &IFF_NAPI_FRAGS );if (err <0 )return err;
@@ -2673,7 +2674,8 @@ static int tun_set_iff(struct net *net, (ifr->ifr_flags &TUN_FEATURES );INIT_LIST_HEAD (&tun->disabled); - err =tun_attach (tun, file, false, ifr->ifr_flags &IFF_NAPI ); + err =tun_attach (tun, file, false, ifr->ifr_flags &IFF_NAPI , + ifr->ifr_flags &IFF_NAPI_FRAGS );if (err <0 ) goto err_free_flow;
@@ -2822,7 +2824,8 @@ static int tun_set_queue(struct file *fi ret =security_tun_dev_attach_queue (tun->security);if (ret <0 ) goto unlock; - ret =tun_attach (tun, file, false, tun->flags &IFF_NAPI ); + ret =tun_attach (tun, file, false, tun->flags &IFF_NAPI , + tun->flags &IFF_NAPI_FRAGS ); }else if (ifr->ifr_flags &IFF_DETACH_QUEUE ) { tun =rtnl_dereference (tfile->tun);if (!tun || !(tun->flags &IFF_MULTI_QUEUE ) || tfile->detached)
Greg Kroah-Hartman
maintainerPATCH 33/135 net: stmmac: Fixup the tail addr setting in xmit path
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jose Abreu <[email protected]>
[ Upstream commit 0431100b3d82c509729ece1ab22ada2484e209c1 ]
Currently we are always setting the tail address of descriptor list to the end of the pre-allocated list.
According to databook this is not correct. Tail address should point to the last available descriptor + 1, which means we have to update the tail address everytime we call the xmit function.
This should make no impact in older versions of MAC but in newer versions there are some DMA features which allows the IP to fetch descriptors in advance and in a non sequential order so its critical that we set the tail address correctly.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +4 -2
@@ -2193,8 +2193,7 @@ static int stmmac_init_dma_engine(structstmmac_init_tx_chan (priv, priv->ioaddr, priv->plat->dma_cfg, tx_q->dma_tx_phy, chan); - tx_q->tx_tail_addr = tx_q->dma_tx_phy + - (DMA_TX_SIZE *sizeof (struct dma_desc )); + tx_q->tx_tail_addr = tx_q->dma_tx_phy;stmmac_set_tx_tail_ptr (priv, priv->ioaddr, tx_q->tx_tail_addr, chan); }
@@ -2971,6 +2970,7 @@ static netdev_tx_t stmmac_tso_xmit(strucnetdev_tx_sent_queue (netdev_get_tx_queue (dev, queue), skb->len); + tx_q->tx_tail_addr = tx_q->dma_tx_phy + (tx_q->cur_tx *sizeof (*desc));stmmac_set_tx_tail_ptr (priv, priv->ioaddr, tx_q->tx_tail_addr, queue);return NETDEV_TX_OK ;
@@ -3178,6 +3178,8 @@ static netdev_tx_t stmmac_xmit(struct sknetdev_tx_sent_queue (netdev_get_tx_queue (dev, queue), skb->len);stmmac_enable_dma_transmission (priv, priv->ioaddr); + + tx_q->tx_tail_addr = tx_q->dma_tx_phy + (tx_q->cur_tx *sizeof (*desc));stmmac_set_tx_tail_ptr (priv, priv->ioaddr, tx_q->tx_tail_addr, queue);return NETDEV_TX_OK ;
Greg Kroah-Hartman
maintainerPATCH 34/135 net/packet: fix packet drop as of virtio gso
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jianfeng Tan <[email protected]>
[ Upstream commit 9d2f67e43b73e8af7438be219b66a5de0cfa8bd9 ]
When we use raw socket as the vhost backend, a packet from virito with gso offloading information, cannot be sent out in later validaton at xmit path, as we did not set correct skb->protocol which is further used for looking up the gso function.
To fix this, we set this field according to virito hdr information.
--- include/linux/virtio_net.h | 18 ++++++++++++++++++ net/packet/af_packet.c | 11 +++++++---- 2 files changed, 25 insertions(+), 4 deletions(-)
include/linux/virtio_net.h +18 -0
@@ -5,6 +5,24 @@#include <linux/if_vlan.h> #include <uapi/linux/virtio_net.h> +static inline int virtio_net_hdr_set_proto (struct sk_buff *skb, +const struct virtio_net_hdr *hdr) +{ +switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN ) { +case VIRTIO_NET_HDR_GSO_TCPV4 : +case VIRTIO_NET_HDR_GSO_UDP : + skb->protocol =cpu_to_be16 (ETH_P_IP ); +break ; +case VIRTIO_NET_HDR_GSO_TCPV6 : + skb->protocol =cpu_to_be16 (ETH_P_IPV6 ); +break ; +default : +return -EINVAL ; + } + +return 0 ; +} +static inline int virtio_net_hdr_to_skb (struct sk_buff *skb,const struct virtio_net_hdr *hdr,bool little_endian)
net/packet/af_packet.c +7 -4
@@ -2712,10 +2712,12 @@ tpacket_error: } } -if (po->has_vnet_hdr &&virtio_net_hdr_to_skb (skb, vnet_hdr, -vio_le ())) { - tp_len = -EINVAL ; - goto tpacket_error; +if (po->has_vnet_hdr) { +if (virtio_net_hdr_to_skb (skb, vnet_hdr,vio_le ())) { + tp_len = -EINVAL ; + goto tpacket_error; + } +virtio_net_hdr_set_proto (skb, vnet_hdr); } skb->destructor = tpacket_destruct_skb;
@@ -2911,6 +2913,7 @@ static int packet_snd(struct socket *socif (err) goto out_free; len +=sizeof (vnet_hdr); +virtio_net_hdr_set_proto (skb, &vnet_hdr); }skb_probe_transport_header (skb, reserve);
Greg Kroah-Hartman
maintainerPATCH 35/135 net: dsa: bcm_sf2: Fix unbind ordering
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit bf3b452b7af787b8bf27de6490dc4eedf6f97599 ]
The order in which we release resources is unfortunately leading to bus errors while dismantling the port. This is because we set priv->wol_ports_mask to 0 to tell bcm_sf2_sw_suspend() that it is now permissible to clock gate the switch. Later on, when dsa_slave_destroy() comes in from dsa_unregister_switch() and calls dsa_switch_ops::port_disable, we perform the same dismantling again, and this time we hit registers that are clock gated.
Make sure that dsa_unregister_switch() is the first thing that happens, which takes care of releasing all user visible resources, then proceed with clock gating hardware. We still need to set priv->wol_ports_mask to 0 to make sure that an enabled port properly gets disabled in case it was previously used as part of Wake-on-LAN.
--- drivers/net/dsa/bcm_sf2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/dsa/bcm_sf2.c +2 -2
@@ -1160,10 +1160,10 @@ static int bcm_sf2_sw_remove(struct plat {struct bcm_sf2_priv *priv =platform_get_drvdata (pdev); -/* Disable all ports and interrupts */ priv->wol_ports_mask =0 ; -bcm_sf2_sw_suspend (priv->dev->ds);dsa_unregister_switch (priv->dev->ds); +/* Disable all ports and interrupts */ +bcm_sf2_sw_suspend (priv->dev->ds);bcm_sf2_mdio_unregister (priv);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 37/135 net: aquantia: memory corruption on jumbo frames
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Friedemann Gerold <[email protected]>
[ Upstream commit d26ed6b0e5e23190d43ab34bc69cbecdc464a2cf ]
This patch fixes skb_shared area, which will be corrupted upon reception of 4K jumbo packets.
Originally build_skb usage purpose was to reuse page for skb to eliminate needs of extra fragments. But that logic does not take into account that skb_shared_info should be reserved at the end of skb data area.
In case packet data consumes all the page (4K), skb_shinfo location overflows the page. As a consequence, __build_skb zeroed shinfo data above the allocated page, corrupting next page.
The issue is rarely seen in real life because jumbo are normally larger than 4K and that causes another code path to trigger.
But it 100% reproducible with simple scapy packet, like:
sendp(IP(dst="192.168.100.3") / TCP(dport=443) \
/ Raw(RandString(size=(4096-40))), iface="enp1s0")--- drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 32 ++++++++++++----------- 1 file changed, 18 insertions(+), 14 deletions(-)
drivers/net/ethernet/aquantia/atlantic/aq_ring.c +18 -14
@@ -225,9 +225,10 @@ int aq_ring_rx_clean(struct aq_ring_s *s }/* for single fragment packets use build_skb() */ -if (buff->is_eop) { +if (buff->is_eop && + buff->len <=AQ_CFG_RX_FRAME_MAX -AQ_SKB_ALIGN ) { skb =build_skb (page_address (buff->page), - buff->len +AQ_SKB_ALIGN ); +AQ_CFG_RX_FRAME_MAX );if (unlikely (!skb)) { err = -ENOMEM ; goto err_exit;
@@ -247,18 +248,21 @@ int aq_ring_rx_clean(struct aq_ring_s *s buff->len -ETH_HLEN , SKB_TRUESIZE(buff->len - ETH_HLEN)); -for (i =1U , next_ = buff->next, - buff_ = &self->buff_ring[next_]; true; - next_ = buff_->next, - buff_ = &self->buff_ring[next_], ++i) { -skb_add_rx_frag (skb, i, buff_->page,0 , - buff_->len, -SKB_TRUESIZE (buff->len - -ETH_HLEN )); - buff_->is_cleaned =1 ; - -if (buff_->is_eop) -break ; +if (!buff->is_eop) { +for (i =1U , next_ = buff->next, + buff_ = &self->buff_ring[next_]; + true; next_ = buff_->next, + buff_ = &self->buff_ring[next_], ++i) { +skb_add_rx_frag (skb, i, + buff_->page,0 , + buff_->len, +SKB_TRUESIZE (buff->len - +ETH_HLEN )); + buff_->is_cleaned =1 ; + +if (buff_->is_eop) +break ; + } } }
Greg Kroah-Hartman
maintainerPATCH 4/135 ip6_tunnel: be careful when accessing the inner header
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
[ Upstream commit 76c0ddd8c3a683f6e2c6e60e11dc1a1558caf4bc ]
the ip6 tunnel xmit ndo assumes that the processed skb always contains an ip[v6] header, but syzbot has found a way to send frames that fall short of this assumption, leading to the following splat:
BUG: KMSAN: uninit-value in ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline] BUG: KMSAN: uninit-value in ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390 CPU: 0 PID: 4504 Comm: syz-executor558 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683 ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline] ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390 __netdev_start_xmit include/linux/netdevice.h:4066 [inline] netdev_start_xmit include/linux/netdevice.h:4075 [inline] xmit_one net/core/dev.c:3026 [inline] dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042 __dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590 packet_snd net/packet/af_packet.c:2944 [inline] packet_sendmsg+0x7c70/0x8a30 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046 __sys_sendmmsg+0x42d/0x800 net/socket.c:2136 SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167 SyS_sendmmsg+0x63/0x90 net/socket.c:2162 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x441819 RSP: 002b:00007ffe58ee8268 EFLAGS: 00000213 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441819 RDX: 0000000000000002 RSI: 0000000020000100 RDI: 0000000000000003 RBP: 00000000006cd018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000402510 R13: 00000000004025a0 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2737 [inline] __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369 __kmalloc_reserve net/core/skbuff.c:138 [inline] __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206 alloc_skb include/linux/skbuff.h:984 [inline] alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085 packet_alloc_skb net/packet/af_packet.c:2803 [inline] packet_snd net/packet/af_packet.c:2894 [inline] packet_sendmsg+0x6454/0x8a30 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046 __sys_sendmmsg+0x42d/0x800 net/socket.c:2136 SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167 SyS_sendmmsg+0x63/0x90 net/socket.c:2162 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
This change addresses the issue adding the needed check before accessing the inner header.
The ipv4 side of the issue is apparently there since the ipv4 over ipv6 initial support, and the ipv6 side predates git history.
--- net/ipv6/ip6_tunnel.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
net/ipv6/ip6_tunnel.c +11 -2
@@ -1226,7 +1226,7 @@ static inline int ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev) { struct ip6_tnl *t = netdev_priv(dev); -const struct iphdr *iph =ip_hdr (skb); +const struct iphdr *iph;int encap_limit =-1 ;struct flowi6 fl6;__u8 dsfield;
@@ -1234,6 +1234,11 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, stru8 tproto;int err; +/* ensure we can access the full inner ip header */ +if (!pskb_may_pull (skb,sizeof (struct iphdr ))) +return -1 ; + + iph =ip_hdr (skb);memset (&(IPCB (skb)->opt),0 ,sizeof (IPCB (skb)->opt)); tproto =READ_ONCE (t->parms.proto);
@@ -1297,7 +1302,7 @@ static inline int ip6ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev) { struct ip6_tnl *t = netdev_priv(dev); -struct ipv6hdr *ipv6h =ipv6_hdr (skb); +struct ipv6hdr *ipv6h;int encap_limit =-1 ;__u16 offset;struct flowi6 fl6;
@@ -1306,6 +1311,10 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, stru8 tproto;int err; +if (unlikely (!pskb_may_pull (skb,sizeof (*ipv6h)))) +return -1 ; + + ipv6h =ipv6_hdr (skb); tproto =READ_ONCE (t->parms.proto);if ((tproto !=IPPROTO_IPV6 && tproto !=0 ) ||ip6_tnl_addr_conflict (t, ipv6h))
Greg Kroah-Hartman
maintainerPATCH 5/135 ip_tunnel: be careful when accessing the inner header
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
[ Upstream commit ccfec9e5cb2d48df5a955b7bf47f7782157d3bc2]
Cong noted that we need the same checks introduced by commit 76c0ddd8c3a6 ("ip6_tunnel: be careful when accessing the inner header") even for ipv4 tunnels.
--- net/ipv4/ip_tunnel.c | 9 +++++++++ 1 file changed, 9 insertions(+)
net/ipv4/ip_tunnel.c +9 -0
@@ -627,6 +627,7 @@ void ip_tunnel_xmit(struct sk_buff *skb, const struct iphdr *tnl_params, u8 protocol) {struct ip_tunnel *tunnel =netdev_priv (dev); +unsigned int inner_nhdr_len =0 ;const struct iphdr *inner_iph;struct flowi4 fl4;u8 tos, ttl;
@@ -636,6 +637,14 @@ void ip_tunnel_xmit(struct sk_buff *skb,__be32 dst;bool connected; +/* ensure we can access the inner net header, for several users below */ +if (skb->protocol ==htons (ETH_P_IP )) + inner_nhdr_len =sizeof (struct iphdr ); +else if (skb->protocol ==htons (ETH_P_IPV6 )) + inner_nhdr_len =sizeof (struct ipv6hdr ); +if (unlikely (!pskb_may_pull (skb, inner_nhdr_len))) + goto tx_error; + inner_iph = (const struct iphdr *)skb_inner_network_header (skb); connected = (tunnel->parms.iph.daddr !=0 );
Greg Kroah-Hartman
maintainerPATCH 7/135 ipv6: take rcu lock in rawv6_send_hdrinc()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Wang <[email protected]>
[ Upstream commit a688caa34beb2fd2a92f1b6d33e40cde433ba160 ]
In rawv6_send_hdrinc(), in order to avoid an extra dst_hold(), we directly assign the dst to skb and set passed in dst to NULL to avoid double free.
However, in error case, we free skb and then do stats update with the dst pointer passed in. This causes use-after-free on the dst. Fix it by taking rcu read lock right before dst could get released to make sure dst does not get freed until the stats update is done.
Note: we don't have this issue in ipv4 cause dst is not used for stats update in v4.
Syzkaller reported following crash:
BUG: KASAN: use-after-free in rawv6_send_hdrinc net/ipv6/raw.c:692 [inline] BUG: KASAN: use-after-free in rawv6_sendmsg+0x4421/0x4630 net/ipv6/raw.c:921 Read of size 8 at addr ffff8801d95ba730 by task syz-executor0/32088 CPU: 1 PID: 32088 Comm: syz-executor0 Not tainted 4.19.0-rc2+ #93 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 rawv6_send_hdrinc net/ipv6/raw.c:692 [inline] rawv6_sendmsg+0x4421/0x4630 net/ipv6/raw.c:921 inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x280 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457099 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f83756edc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f83756ee6d4 RCX: 0000000000457099 RDX: 0000000000000000 RSI: 0000000020003840 RDI: 0000000000000004 RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000004d4b30 R14: 00000000004c90b1 R15: 0000000000000000 Allocated by task 32088: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554 dst_alloc+0xbb/0x1d0 net/core/dst.c:105 ip6_dst_alloc+0x35/0xa0 net/ipv6/route.c:353 ip6_rt_cache_alloc+0x247/0x7b0 net/ipv6/route.c:1186 ip6_pol_route+0x8f8/0xd90 net/ipv6/route.c:1895 ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2093 fib6_rule_lookup+0x277/0x860 net/ipv6/fib6_rules.c:122 ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:2121 ip6_route_output include/net/ip6_route.h:88 [inline] ip6_dst_lookup_tail+0xe27/0x1d60 net/ipv6/ip6_output.c:951 ip6_dst_lookup_flow+0xc8/0x270 net/ipv6/ip6_output.c:1079 rawv6_sendmsg+0x12d9/0x4630 net/ipv6/raw.c:905 inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x280 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5356: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x290 mm/slab.c:3756 dst_destroy+0x267/0x3c0 net/core/dst.c:141 dst_destroy_rcu+0x16/0x19 net/core/dst.c:154 __rcu_reclaim kernel/rcu/rcu.h:236 [inline] rcu_do_batch kernel/rcu/tree.c:2576 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2847 [inline] rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864 __do_softirq+0x30b/0xad8 kernel/softirq.c:292
--- net/ipv6/raw.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)
net/ipv6/raw.c +20 -9
@@ -650,8 +650,6 @@ static int rawv6_send_hdrinc(struct sock skb->protocol =htons (ETH_P_IPV6 ); skb->priority = sk->sk_priority; skb->mark = sk->sk_mark; -skb_dst_set (skb, &rt->dst); - *dstp =NULL ;skb_put (skb, length);skb_reset_network_header (skb);
@@ -664,8 +662,14 @@ static int rawv6_send_hdrinc(struct sock skb->transport_header = skb->network_header; err =memcpy_from_msg (iph, msg, length); -if (err) - goto error_fault; +if (err) { + err = -EFAULT ; +kfree_skb (skb); + goto error; + } + +skb_dst_set (skb, &rt->dst); + *dstp =NULL ;/* if egress device is enslaved to an L3 master device pass the * skb to its handler for processing
@@ -674,21 +678,28 @@ static int rawv6_send_hdrinc(struct sockif (unlikely (!skb))return 0 ; +/* Acquire rcu_read_lock() in case we need to use rt->rt6i_idev +* in the error path. Since skb has been freed, the dst could +* have been queued for deletion. +*/ +rcu_read_lock ();IP6_UPD_PO_STATS (net, rt->rt6i_idev,IPSTATS_MIB_OUT , skb->len); err =NF_HOOK (NFPROTO_IPV6 ,NF_INET_LOCAL_OUT , net, sk, skb,NULL , rt->dst.dev, dst_output);if (err >0 ) err =net_xmit_errno (err); -if (err) - goto error; +if (err) { +IP6_INC_STATS (net, rt->rt6i_idev,IPSTATS_MIB_OUTDISCARDS ); +rcu_read_unlock (); + goto error_check; + } +rcu_read_unlock (); out:return 0 ; -error_fault: - err = -EFAULT ; -kfree_skb (skb); error:IP6_INC_STATS (net, rt->rt6i_idev,IPSTATS_MIB_OUTDISCARDS ); +error_check:if (err == -ENOBUFS && !np->recverr) err =0 ;return err;
Greg Kroah-Hartman
maintainerPATCH 9/135 net: hns: fix for unmapping problem when SMMU is on
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yunsheng Lin <[email protected]>
[ Upstream commit 2e9361efa707e186d91b938e44f9e326725259f7 ]
If SMMU is on, there is more likely that skb_shinfo(skb)->frags[i] can not send by a single BD. when this happen, the hns_nic_net_xmit_hw function map the whole data in a frags using skb_frag_dma_map, but unmap each BD' data individually when tx is done, which causes problem when SMMU is on.
This patch fixes this problem by ummapping the whole data in a frags when tx is done.
--- drivers/net/ethernet/hisilicon/hns/hnae.c | 2 - drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 ++++++++++++++++---------- 2 files changed, 20 insertions(+), 12 deletions(-)
drivers/net/ethernet/hisilicon/hns/hnae.c +1 -1
@@ -84,7 +84,7 @@ static void hnae_unmap_buffer(struct hnaif (cb->type ==DESC_TYPE_SKB )dma_unmap_single (ring_to_dev (ring), cb->dma, cb->length,ring_to_dma_dir (ring)); -else +else if (cb->length)dma_unmap_page (ring_to_dev (ring), cb->dma, cb->length,ring_to_dma_dir (ring)); }
drivers/net/ethernet/hisilicon/hns/hns_enet.c +19 -11
@@ -40,9 +40,9 @@#define SKB_TMP_LEN (SKB ) \ (((SKB)->transport_header - (SKB)->mac_header) + tcp_hdrlen(SKB)) -static void fill_v2_desc (struct hnae_ring *ring,void *priv, -int size,dma_addr_t dma,int frag_end, -int buf_num,enum hns_desc_type type,int mtu) +static void fill_v2_desc_hw (struct hnae_ring *ring,void *priv,int size, +int send_sz,dma_addr_t dma,int frag_end, +int buf_num,enum hns_desc_type type,int mtu) {struct hnae_desc *desc = &ring->desc[ring->next_to_use];struct hnae_desc_cb *desc_cb = &ring->desc_cb[ring->next_to_use];
@@ -64,7 +64,7 @@ static void fill_v2_desc(struct hnae_rin desc_cb->type = type; desc->addr =cpu_to_le64 (dma); - desc->tx.send_size =cpu_to_le16 ((u16 )size); + desc->tx.send_size =cpu_to_le16 ((u16 )send_sz);/* config bd buffer end */ hnae_set_bit (rrcfv,HNSV2_TXD_VLD_B ,1 );
@@ -133,6 +133,14 @@ static void fill_v2_desc(struct hnae_rinring_ptr_move_fw (ring, next_to_use); } +static void fill_v2_desc (struct hnae_ring *ring,void *priv, +int size,dma_addr_t dma,int frag_end, +int buf_num,enum hns_desc_type type,int mtu) +{ +fill_v2_desc_hw (ring, priv, size, size, dma, frag_end, + buf_num, type, mtu); +} +static const struct acpi_device_id hns_enet_acpi_match[] = { {"HISI00C1" ,0 }, {"HISI00C2" ,0 },
@@ -289,15 +297,15 @@ static void fill_tso_desc(struct hnae_ri/* when the frag size is bigger than hardware, split this frag */ for (k =0 ; k < frag_buf_num; k++) -fill_v2_desc (ring, priv, - (k == frag_buf_num -1 ) ? +fill_v2_desc_hw (ring, priv, k ==0 ? size :0 , + (k == frag_buf_num -1 ) ? sizeoflast :BD_MAX_SEND_SIZE , - dma +BD_MAX_SEND_SIZE * k, - frag_end && (k == frag_buf_num -1 ) ?1 :0 , - buf_num, - (type ==DESC_TYPE_SKB && !k) ? + dma +BD_MAX_SEND_SIZE * k, + frag_end && (k == frag_buf_num -1 ) ?1 :0 , + buf_num, + (type ==DESC_TYPE_SKB && !k) ?DESC_TYPE_SKB :DESC_TYPE_PAGE , - mtu); + mtu); } netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
Greg Kroah-Hartman
maintainerPATCH 39/135 bonding: pass link-local packets to bonding master also.
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Bandewar <[email protected]>
[ Upstream commit 6a9e461f6fe4434e6172304b69774daff9a3ac4c ]
Commit b89f04c61efe ("bonding: deliver link-local packets with skb->dev set to link that packets arrived on") changed the behavior of how link-local-multicast packets are processed. The change in the behavior broke some legacy use cases where these packets are expected to arrive on bonding master device also.
This patch passes the packet to the stack with the link it arrived on as well as passes to the bonding-master device to preserve the legacy use case.
--- drivers/net/bonding/bond_main.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)
drivers/net/bonding/bond_main.c +19 -2
@@ -1178,9 +1178,26 @@ static rx_handler_result_t bond_handle_f } } -/* don't change skb->dev for link-local packets */ -if (is_link_local_ether_addr (eth_hdr (skb)->h_dest)) +/* Link-local multicast packets should be passed to the +* stack on the link they arrive as well as pass them to the +* bond-master device. These packets are mostly usable when +* stack receives it with the link on which they arrive +* (e.g. LLDP) they also must be available on master. Some of +* the use cases include (but are not limited to): LLDP agents +* that must be able to operate both on enslaved interfaces as +* well as on bonds themselves; linux bridges that must be able +* to process/pass BPDUs from attached bonds when any kind of +* STP version is enabled on the network. +*/ +if (is_link_local_ether_addr (eth_hdr (skb)->h_dest)) { +struct sk_buff *nskb =skb_clone (skb,GFP_ATOMIC ); + +if (nskb) { + nskb->dev = bond->dev; +netif_rx (nskb); + }return RX_HANDLER_PASS ; + }if (bond_should_deliver_exact_match (skb, slave, bond))return RX_HANDLER_EXACT ;
Greg Kroah-Hartman
maintainerPATCH 48/135 inet: make sure to grab rcu_read_lock before using ireq->ireq_opt
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 2ab2ddd301a22ca3c5f0b743593e4ad2953dfa53 ]
Timer handlers do not imply rcu_read_lock(), so my recent fix triggered a LOCKDEP warning when SYNACK is retransmit.
Lets add rcu_read_lock()/rcu_read_unlock() pairs around ireq->ireq_opt usages instead of guessing what is done by callers, since it is not worth the pain.
Get rid of ireq_opt_deref() helper since it hides the logic without real benefit, since it is now a standard rcu_dereference().
--- include/net/inet_sock.h | 5 ----- net/dccp/ipv4.c | 4 +++- net/ipv4/inet_connection_sock.c | 5 ++++- net/ipv4/tcp_ipv4.c | 4 +++- 4 files changed, 10 insertions(+), 8 deletions(-)
include/net/inet_sock.h +0 -5
@@ -130,11 +130,6 @@ static inline int inet_request_bound_devreturn sk->sk_bound_dev_if; } -static inline struct ip_options_rcu *ireq_opt_deref (const struct inet_request_sock *ireq) -{ -return rcu_dereference (ireq->ireq_opt); -} -struct inet_cork {unsigned int flags;__be32 addr;
net/dccp/ipv4.c +3 -1
@@ -493,9 +493,11 @@ static int dccp_v4_send_response(const s dh->dccph_checksum =dccp_v4_csum_finish (skb, ireq->ir_loc_addr, ireq->ir_rmt_addr); +rcu_read_lock (); err =ip_build_and_send_pkt (skb, sk, ireq->ir_loc_addr, ireq->ir_rmt_addr, -ireq_opt_deref (ireq)); +rcu_dereference (ireq->ireq_opt)); +rcu_read_unlock (); err =net_xmit_eval (err); }
net/ipv4/inet_connection_sock.c +4 -1
@@ -535,7 +535,8 @@ struct dst_entry *inet_csk_route_req(construct ip_options_rcu *opt;struct rtable *rt; - opt =ireq_opt_deref (ireq); +rcu_read_lock (); + opt =rcu_dereference (ireq->ireq_opt); flowi4_init_output(fl4, ireq->ir_iif, ireq->ir_mark, RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
@@ -549,11 +550,13 @@ struct dst_entry *inet_csk_route_req(con goto no_route;if (opt && opt->opt.is_strictroute && rt->rt_uses_gateway) goto route_err; +rcu_read_unlock ();return &rt->dst; route_err:ip_rt_put (rt); no_route: +rcu_read_unlock ();__IP_INC_STATS (net,IPSTATS_MIB_OUTNOROUTES );return NULL ; }
net/ipv4/tcp_ipv4.c +3 -1
@@ -942,9 +942,11 @@ static int tcp_v4_send_synack(const struif (skb) {__tcp_v4_send_check (skb, ireq->ir_loc_addr, ireq->ir_rmt_addr); +rcu_read_lock (); err =ip_build_and_send_pkt (skb, sk, ireq->ir_loc_addr, ireq->ir_rmt_addr, -ireq_opt_deref (ireq)); +rcu_dereference (ireq->ireq_opt)); +rcu_read_unlock (); err =net_xmit_eval (err); }
Greg Kroah-Hartman
maintainerPATCH 49/135 net: dsa: b53: Keep CPU port as tagged in all VLANs
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit ca8931948344c485569b04821d1f6bcebccd376b ]
Commit c499696e7901 ("net: dsa: b53: Stop using dev->cpu_port incorrectly") was a bit too trigger happy in removing the CPU port from the VLAN membership because we rely on DSA to program the CPU port VLAN, which it does, except it does not bother itself with tagged/untagged and just usese untagged.
Having the CPU port "follow" the user ports tagged/untagged is not great and does not allow for properly differentiating, so keep the CPU port tagged in all VLANs.
--- drivers/net/dsa/b53/b53_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/dsa/b53/b53_common.c +2 -2
@@ -1107,7 +1107,7 @@ void b53_vlan_add(struct dsa_switch *ds,b53_get_vlan_entry (dev, vid, vl); vl->members |=BIT (port); -if (untagged) +if (untagged && !dsa_is_cpu_port (ds, port)) vl->untag |=BIT (port);else vl->untag &= ~BIT (port);
@@ -1149,7 +1149,7 @@ int b53_vlan_del(struct dsa_switch *ds, pvid =0 ; } -if (untagged) +if (untagged && !dsa_is_cpu_port (ds, port)) vl->untag &= ~(BIT (port));b53_set_vlan_entry (dev, vid, vl);
Greg Kroah-Hartman
maintainerPATCH 50/135 rtnetlink: Fail dump if target netnsid is invalid
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
[ Upstream commit 893626d6a353d1356528f94e081246ecf233d77a ]
Link dumps can return results from a target namespace. If the namespace id is invalid, then the dump request should fail if get_target_net fails rather than continuing with a dump of the current namespace.
--- net/core/rtnetlink.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
net/core/rtnetlink.c +2 -4
@@ -1848,10 +1848,8 @@ static int rtnl_dump_ifinfo(struct sk_buif (tb[IFLA_IF_NETNSID ]) { netnsid =nla_get_s32 (tb[IFLA_IF_NETNSID ]); tgt_net =get_target_net (skb->sk, netnsid); -if (IS_ERR (tgt_net)) { - tgt_net = net; - netnsid =-1 ; - } +if (IS_ERR (tgt_net)) +return PTR_ERR (tgt_net); }if (tb[IFLA_EXT_MASK ])
Greg Kroah-Hartman
maintainerPATCH 52/135 net: ipv4: dont let PMTU updates increase route MTU
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
[ Upstream commit 28d35bcdd3925e7293408cdb8aa5f2aac5f0d6e3 ]
When an MTU update with PMTU smaller than net.ipv4.route.min_pmtu is received, we must clamp its value. However, we can receive a PMTU exception with PMTU < old_mtu < ip_rt_min_pmtu, which would lead to an increase in PMTU.
To fix this, take the smallest of the old MTU and ip_rt_min_pmtu.
Before this patch, in case of an update, the exception's MTU would always change. Now, an exception can have only its lock flag updated, but not the MTU, so we need to add a check on locking to the following "is this exception getting updated, or close to expiring?" test.
--- net/ipv4/route.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/ipv4/route.c +4 -3
@@ -1001,21 +1001,22 @@ out: kfree_skb(skb);static void __ip_rt_update_pmtu (struct rtable *rt,struct flowi4 *fl4,u32 mtu) {struct dst_entry *dst = &rt->dst; +u32 old_mtu =ipv4_mtu (dst);struct fib_result res;bool lock = false;if (ip_mtu_locked (dst))return ; -if (ipv4_mtu (dst) < mtu) +if (old_mtu < mtu)return ;if (mtu < ip_rt_min_pmtu) { lock = true; - mtu = ip_rt_min_pmtu; + mtu =min (old_mtu, ip_rt_min_pmtu); } -if (rt->rt_pmtu == mtu && +if (rt->rt_pmtu == mtu && !lock &&time_before (jiffies, dst->expires - ip_rt_mtu_expires /2 ))return ;
Greg Kroah-Hartman
maintainerPATCH 53/135 net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alaa Hleihel <[email protected]>
[ Upstream commit 6b359d5550a1ae7a1269c9dc1dd73dfdc4d6fe58 ]
When modifying hairpin SQ, instead of checking if the next state equals to MLX5_SQC_STATE_RDY, we compare it against the MLX5_RQC_STATE_RDY enum value.
The code worked since both of MLX5_RQC_STATE_RDY and MLX5_SQC_STATE_RDY have the same value today.
This patch fixes this issue.
--- drivers/net/ethernet/mellanox/mlx5/core/transobj.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/transobj.c +1 -1
@@ -509,7 +509,7 @@ static int mlx5_hairpin_modify_sq(struct sqc =MLX5_ADDR_OF (modify_sq_in, in, ctx); -if (next_state ==MLX5_RQC_STATE_RDY ) { +if (next_state ==MLX5_SQC_STATE_RDY ) {MLX5_SET (sqc, sqc, hairpin_peer_rq, peer_rq);MLX5_SET (sqc, sqc, hairpin_peer_vhca, peer_vhca); }
Greg Kroah-Hartman
maintainerPATCH 54/135 bnxt_en: Fix enables field in HWRM_QUEUE_COS2BW_CFG request
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasundhara Volam <[email protected]>
[ Upstream commit 5db0e0969af6501ad45fe0494039d3b9c797822b ]
In HWRM_QUEUE_COS2BW_CFG request, enables field should have the bits set only for the queue ids which are having the valid parameters.
This causes firmware to return error when the TC to hardware CoS queue mapping is not 1:1 during DCBNL ETS setup.
--- drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c +3 -3
@@ -98,13 +98,13 @@ static int bnxt_hwrm_queue_cos2bw_cfg(stbnxt_hwrm_cmd_hdr_init (bp, &req,HWRM_QUEUE_COS2BW_CFG ,-1 ,-1 );for (i =0 ; i < max_tc; i++) { -u8 qidx; +u8 qidx = bp->tc_to_qidx[i]; req.enables |=cpu_to_le32 ( -QUEUE_COS2BW_CFG_REQ_ENABLES_COS_QUEUE_ID0_VALID << i); +QUEUE_COS2BW_CFG_REQ_ENABLES_COS_QUEUE_ID0_VALID << + qidx);memset (&cos2bw,0 ,sizeof (cos2bw)); - qidx = bp->tc_to_qidx[i]; cos2bw.queue_id = bp->q_info[qidx].queue_id;if (ets->tc_tsa[i] ==IEEE_8021QAZ_TSA_STRICT ) { cos2bw.tsa =
Greg Kroah-Hartman
maintainerPATCH 55/135 bnxt_en: get the reduced max_irqs by the ones used by RDMA
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasundhara Volam <[email protected]>
[ Upstream commit c78fe058879bdea919d44f23e21da26f603e9166 ]
When getting the max rings supported, get the reduced max_irqs by the ones used by RDMA.
If the number MSIX is the limiting factor, this bug may cause the max ring count to be higher than it should be when RDMA driver is loaded and may result in ring allocation failures.
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +1 -1
@@ -8501,7 +8501,7 @@ static void _bnxt_get_max_rings(struct b *max_tx = hw_resc->max_tx_rings; *max_rx = hw_resc->max_rx_rings; *max_cp =min_t (int,bnxt_get_max_func_cp_rings_for_en (bp), - hw_resc->max_irqs); + hw_resc->max_irqs -bnxt_get_ulp_msix_num (bp)); *max_cp =min_t (int, *max_cp, hw_resc->max_stat_ctxs); max_ring_grps = hw_resc->max_hw_ring_grps;if (BNXT_CHIP_TYPE_NITRO_A0 (bp) &&BNXT_PF (bp)) {
Greg Kroah-Hartman
maintainerPATCH 56/135 net/ipv6: Remove extra call to ip6_convert_metrics for multipath case
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
[ Upstream commit 36f19d5b4f99fa9fa8263877e5f8e669d7fddc14 ]
The change to move metrics from the dst to rt6_info moved the call to ip6_convert_metrics from ip6_route_add to ip6_route_info_create. In doing so it makes the call in ip6_route_info_append redundant and actually leaks the metrics installed as part of the ip6_route_info_create. Remove the now unnecessary call.
--- net/ipv6/route.c | 5 ----- 1 file changed, 5 deletions(-)
net/ipv6/route.c +0 -5
@@ -4314,11 +4314,6 @@ static int ip6_route_info_append(structif (!nh)return -ENOMEM ; nh->fib6_info = rt; - err =ip6_convert_metrics (net, rt, r_cfg); -if (err) { -kfree (nh); -return err; - }memcpy (&nh->r_cfg, r_cfg,sizeof (*r_cfg));list_add_tail (&nh->next, rt6_nh_list);
Greg Kroah-Hartman
maintainerPATCH 57/135 net/ipv6: stop leaking percpu memory in fib6 info
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Rapoport <[email protected]>
[ Upstream commit 7abab7b9b498650404800a08765f44929fee8f31 ]
The fib6_info_alloc() function allocates percpu memory to hold per CPU pointers to rt6_info, but this memory is never freed. Fix it.
--- net/ipv6/ip6_fib.c | 2 ++ 1 file changed, 2 insertions(+)
net/ipv6/ip6_fib.c +2 -0
@@ -196,6 +196,8 @@ void fib6_info_destroy_rcu(struct rcu_he *ppcpu_rt =NULL ; } } + +free_percpu (f6i->rt6i_pcpu); }lwtstate_put (f6i->fib6_nh.nh_lwtstate);
Greg Kroah-Hartman
maintainerPATCH 40/135 bonding: fix warning message
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Bandewar <[email protected]>
[ Upstream commit 0f3b914c9cfcd7bbedd445dc4ac5dd999fa213c2 ]
RX queue config for bonding master could be different from its slave device(s). With the commit 6a9e461f6fe4 ("bonding: pass link-local packets to bonding master also."), the packet is reinjected into stack with skb->dev as bonding master. This potentially triggers the message:
"bondX received packet on queue Y, but number of RX queues is Z"
whenever the queue that packet is received on is higher than the numrxqueues on bonding master (Y > Z).
--- drivers/net/bonding/bond_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/bonding/bond_main.c +1 -0
@@ -1194,6 +1194,7 @@ static rx_handler_result_t bond_handle_fif (nskb) { nskb->dev = bond->dev; + nskb->queue_mapping =0 ;netif_rx (nskb); }return RX_HANDLER_PASS ;
Greg Kroah-Hartman
maintainerPATCH 60/135 r8169: fix network stalls due to missing bit TXCFG_AUTO_FIFO
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
[ Upstream commit ad5f97faff4231e72b96bd96adbe1b6e977a9b86 ]
Some of the chip-specific hw_start functions set bit TXCFG_AUTO_FIFO in register TxConfig. The original patch changed the order of some calls resulting in these changes being overwritten by rtl_set_tx_config_registers() in rtl_hw_start(). This eventually resulted in network stalls especially under high load.
Analyzing the chip-specific hw_start functions all chip version from 34, with the exception of version 39, need this bit set. This patch moves setting this bit to rtl_set_tx_config_registers().
--- drivers/net/ethernet/realtek/r8169.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-)
drivers/net/ethernet/realtek/r8169.c +8 -12
@@ -5041,9 +5041,14 @@ static void rtl8169_hw_reset(struct rtl8static void rtl_set_tx_config_registers (struct rtl8169_private *tp) { -/* Set DMA burst size and Interframe Gap Time */ -RTL_W32 (tp, TxConfig, (TX_DMA_BURST << TxDMAShift) | - (InterFrameGap << TxInterFrameGapShift)); +u32 val =TX_DMA_BURST << TxDMAShift | + InterFrameGap << TxInterFrameGapShift; + +if (tp->mac_version >=RTL_GIGA_MAC_VER_34 && + tp->mac_version !=RTL_GIGA_MAC_VER_39 ) + val |=TXCFG_AUTO_FIFO ; + +RTL_W32 (tp, TxConfig, val); }static void rtl_set_rx_max_size (struct rtl8169_private *tp)
@@ -5530,7 +5535,6 @@ static void rtl_hw_start_8168e_2(structrtl_disable_clock_request (tp); -RTL_W32 (tp, TxConfig,RTL_R32 (tp, TxConfig) |TXCFG_AUTO_FIFO );RTL_W8 (tp,MCU ,RTL_R8 (tp,MCU ) & ~NOW_IS_OOB );/* Adjust EEE LED frequency */
@@ -5562,7 +5566,6 @@ static void rtl_hw_start_8168f(struct rtrtl_disable_clock_request (tp); -RTL_W32 (tp, TxConfig,RTL_R32 (tp, TxConfig) |TXCFG_AUTO_FIFO );RTL_W8 (tp,MCU ,RTL_R8 (tp,MCU ) & ~NOW_IS_OOB );RTL_W8 (tp,DLLPR ,RTL_R8 (tp,DLLPR ) |PFM_EN );RTL_W32 (tp,MISC ,RTL_R32 (tp,MISC ) |PWM_EN );
@@ -5607,8 +5610,6 @@ static void rtl_hw_start_8411(struct rtlstatic void rtl_hw_start_8168g (struct rtl8169_private *tp) { -RTL_W32 (tp, TxConfig,RTL_R32 (tp, TxConfig) |TXCFG_AUTO_FIFO ); -rtl_eri_write (tp,0xc8 ,ERIAR_MASK_0101 ,0x080002 ,ERIAR_EXGMAC );rtl_eri_write (tp,0xcc ,ERIAR_MASK_0001 ,0x38 ,ERIAR_EXGMAC );rtl_eri_write (tp,0xd0 ,ERIAR_MASK_0001 ,0x48 ,ERIAR_EXGMAC );
@@ -5707,8 +5708,6 @@ static void rtl_hw_start_8168h_1(structRTL_W8 (tp, Config5,RTL_R8 (tp, Config5) & ~ASPM_en);rtl_ephy_init (tp, e_info_8168h_1,ARRAY_SIZE (e_info_8168h_1)); -RTL_W32 (tp, TxConfig,RTL_R32 (tp, TxConfig) |TXCFG_AUTO_FIFO ); -rtl_eri_write (tp,0xc8 ,ERIAR_MASK_0101 ,0x00080002 ,ERIAR_EXGMAC );rtl_eri_write (tp,0xcc ,ERIAR_MASK_0001 ,0x38 ,ERIAR_EXGMAC );rtl_eri_write (tp,0xd0 ,ERIAR_MASK_0001 ,0x48 ,ERIAR_EXGMAC );
@@ -5789,8 +5788,6 @@ static void rtl_hw_start_8168ep(struct r {rtl8168ep_stop_cmac (tp); -RTL_W32 (tp, TxConfig,RTL_R32 (tp, TxConfig) |TXCFG_AUTO_FIFO ); -rtl_eri_write (tp,0xc8 ,ERIAR_MASK_0101 ,0x00080002 ,ERIAR_EXGMAC );rtl_eri_write (tp,0xcc ,ERIAR_MASK_0001 ,0x2f ,ERIAR_EXGMAC );rtl_eri_write (tp,0xd0 ,ERIAR_MASK_0001 ,0x5f ,ERIAR_EXGMAC );
@@ -6108,7 +6105,6 @@ static void rtl_hw_start_8402(struct rtl/* Force LAN exit from ASPM if Rx/Tx are not idle */ RTL_W32 (tp, FuncEvent,RTL_R32 (tp, FuncEvent) |0x002800 ); -RTL_W32 (tp, TxConfig,RTL_R32 (tp, TxConfig) |TXCFG_AUTO_FIFO );RTL_W8 (tp,MCU ,RTL_R8 (tp,MCU ) & ~NOW_IS_OOB );rtl_ephy_init (tp, e_info_8402,ARRAY_SIZE (e_info_8402));
Greg Kroah-Hartman
maintainerPATCH 61/135 r8169: set RX_MULTI_EN bit in RxConfig for 8168F-family chips
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Maciej S. Szmigiero" <[email protected]>
[ Upstream commit 511cfd580f23b0e0fcd5659931ef14c6e2c062b0 ]
It has been reported that since
commit 05212ba8132b42 ("r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices") at least RTL_GIGA_MAC_VER_38 NICs work erratically after a resume from
suspend.
The problem has been traced to a missing RX_MULTI_EN bit in the RxConfig register.
We already set this bit for RTL_GIGA_MAC_VER_35 NICs of the same 8168F
chip family so let's do it also for its other siblings: RTL_GIGA_MAC_VER_36
and RTL_GIGA_MAC_VER_38.
Curiously, the NIC seems to work fine after a system boot without having this bit set as long as the system isn't suspended and resumed.
--- drivers/net/ethernet/realtek/r8169.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/realtek/r8169.c +2 -2
@@ -4788,8 +4788,8 @@ static void rtl_init_rxcfg(struct rtl816RTL_W32 (tp, RxConfig,RX_FIFO_THRESH |RX_DMA_BURST );break ; case RTL_GIGA_MAC_VER_18 ... RTL_GIGA_MAC_VER_24: -case RTL_GIGA_MAC_VER_34 : -case RTL_GIGA_MAC_VER_35 : + case RTL_GIGA_MAC_VER_34 ... RTL_GIGA_MAC_VER_36: +case RTL_GIGA_MAC_VER_38 :RTL_W32 (tp, RxConfig,RX128_INT_EN |RX_MULTI_EN |RX_DMA_BURST );break ; case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
Greg Kroah-Hartman
maintainerPATCH 63/135 ASoC: dapm: Fix NULL pointer deference on CODEC to CODEC DAIs
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <[email protected]>
[ Upstream commit 249dc49576fc953a7378b916c6a6d47ea81e4da2 ]
Commit a655de808cbde ("ASoC: core: Allow topology to override machine driver FE DAI link config.") caused soc_dai_hw_params to be come dependent on the substream private_data being set with a pointer to the snd_soc_pcm_runtime. Currently, CODEC to CODEC links don't set this, which causes a NULL pointer dereference:
[<4069de54>] (soc_dai_hw_params) from
[<40694b68>] (snd_soc_dai_link_event+0x1a0/0x380)
Since the ASoC core in general assumes that the substream private_data will be set to a pointer to the snd_soc_pcm_runtime, update the CODEC to CODEC links to respect this.
--- include/sound/soc-dapm.h | 1 + sound/soc/soc-core.c | 4 ++-- sound/soc/soc-dapm.c | 4 ++++ 3 files changed, 7 insertions(+), 2 deletions(-)
include/sound/soc-dapm.h +1 -0
@@ -410,6 +410,7 @@ int snd_soc_dapm_new_dai_widgets(structint snd_soc_dapm_link_dai_widgets (struct snd_soc_card *card);void snd_soc_dapm_connect_dai_link_widgets (struct snd_soc_card *card); int snd_soc_dapm_new_pcm(struct snd_soc_card *card, + struct snd_soc_pcm_runtime *rtd, const struct snd_soc_pcm_stream *params, unsigned int num_params, struct snd_soc_dapm_widget *source,
sound/soc/soc-core.c +2 -2
@@ -1430,7 +1430,7 @@ static int soc_link_dai_widgets(struct s sink = codec_dai->playback_widget; source = cpu_dai->capture_widget;if (sink && source) { - ret =snd_soc_dapm_new_pcm (card, dai_link->params, + ret =snd_soc_dapm_new_pcm (card, rtd, dai_link->params, dai_link->num_params, source, sink);if (ret !=0 ) {
@@ -1443,7 +1443,7 @@ static int soc_link_dai_widgets(struct s sink = cpu_dai->playback_widget; source = codec_dai->capture_widget;if (sink && source) { - ret =snd_soc_dapm_new_pcm (card, dai_link->params, + ret =snd_soc_dapm_new_pcm (card, rtd, dai_link->params, dai_link->num_params, source, sink);if (ret !=0 ) {
sound/soc/soc-dapm.c +4 -0
@@ -3658,6 +3658,7 @@ static int snd_soc_dai_link_event(struct {struct snd_soc_dapm_path *source_p, *sink_p;struct snd_soc_dai *source, *sink; +struct snd_soc_pcm_runtime *rtd = w->priv;const struct snd_soc_pcm_stream *config = w->params + w->params_select;struct snd_pcm_substream substream;struct snd_pcm_hw_params *params =NULL ;
@@ -3717,6 +3718,7 @@ static int snd_soc_dai_link_event(struct goto out; } substream.runtime = runtime; + substream.private_data = rtd;switch (event) {case SND_SOC_DAPM_PRE_PMU :
@@ -3901,6 +3903,7 @@ outfree_w_param: } int snd_soc_dapm_new_pcm(struct snd_soc_card *card, + struct snd_soc_pcm_runtime *rtd, const struct snd_soc_pcm_stream *params, unsigned int num_params, struct snd_soc_dapm_widget *source,
@@ -3969,6 +3972,7 @@ int snd_soc_dapm_new_pcm(struct snd_soc_ w->params = params; w->num_params = num_params; + w->priv = rtd; ret =snd_soc_dapm_add_path (&card->dapm, source, w,NULL ,NULL );if (ret)
Greg Kroah-Hartman
maintainerPATCH 64/135 ASoC: max98373: Added speaker FS gain cotnrol register to volatile.
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryan Lee <[email protected]>
[ Upstream commit 0d22825255f25adb6a609f130b42c752d3fd0f5d ]
--- sound/soc/codecs/max98373.c | 1 + 1 file changed, 1 insertion(+)
sound/soc/codecs/max98373.c +1 -0
@@ -519,6 +519,7 @@ static bool max98373_volatile_reg(struct {switch (reg) { case MAX98373_R2000_SW_RESET ... MAX98373_R2009_INT_FLAG3: +case MAX98373_R203E_AMP_PATH_GAIN :case MAX98373_R2054_MEAS_ADC_PVDD_CH_READBACK :case MAX98373_R2055_MEAS_ADC_THERM_CH_READBACK :case MAX98373_R20B6_BDE_CUR_STATE_READBACK :
Greg Kroah-Hartman
maintainerPATCH 65/135 ASoC: rt5514: Fix the issue of the delay volume applied again
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oder Chiou <[email protected]>
[ Upstream commit 6f0a256253f48095ba2e5bcdfbed41f21643c105 ]
After our evaluation, we need to modify the default values to make sure the volume applied immediately.
--- sound/soc/codecs/rt5514.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
sound/soc/codecs/rt5514.c +4 -4
@@ -64,8 +64,8 @@ static const struct reg_sequence rt5514_ {RT5514_ANA_CTRL_LDO10, 0x00028604}, {RT5514_ANA_CTRL_ADCFED, 0x00000800}, {RT5514_ASRC_IN_CTRL1, 0x00000003}, - {RT5514_DOWNFILTER0_CTRL3, 0x10000352}, - {RT5514_DOWNFILTER1_CTRL3, 0x10000352}, + {RT5514_DOWNFILTER0_CTRL3, 0x10000342}, + {RT5514_DOWNFILTER1_CTRL3, 0x10000342}, }; static const struct reg_default rt5514_reg[] = {
@@ -92,10 +92,10 @@ static const struct reg_default rt5514_r {RT5514_ASRC_IN_CTRL1, 0x00000003}, {RT5514_DOWNFILTER0_CTRL1, 0x00020c2f}, {RT5514_DOWNFILTER0_CTRL2, 0x00020c2f}, - {RT5514_DOWNFILTER0_CTRL3, 0x10000352}, + {RT5514_DOWNFILTER0_CTRL3, 0x10000342}, {RT5514_DOWNFILTER1_CTRL1, 0x00020c2f}, {RT5514_DOWNFILTER1_CTRL2, 0x00020c2f}, - {RT5514_DOWNFILTER1_CTRL3, 0x10000352}, + {RT5514_DOWNFILTER1_CTRL3, 0x10000342}, {RT5514_ANA_CTRL_LDO10, 0x00028604}, {RT5514_ANA_CTRL_LDO18_16, 0x02000345}, {RT5514_ANA_CTRL_ADC12, 0x0000a2a8},
Greg Kroah-Hartman
maintainerPATCH 66/135 selftests: android: move config up a level
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anders Roxell <[email protected]>
[ Upstream commit 88bc243a3f22b9938c0b53c577dee28025cdb920 ]
'make kselftest-merge' assumes that the config files for the tests are located under the 'main' test dir, like tools/testing/selftests/android/ and not in a subdir to android.
---
tools/testing/selftests/android/{ion => }/config | 0
tools/testing/selftests/android/config | 5 +++++
tools/testing/selftests/android/ion/config | 5 -----
2 files changed, 5 insertions(+), 5 deletions(-)
rename tools/testing/selftests/android/{ion => }/config (100%)tools/testing/selftests/android/config new file +5 -0
@@ -0,0 +1,5 @@ +CONFIG_ANDROID=y +CONFIG_STAGING=y +CONFIG_ION=y +CONFIG_ION_SYSTEM_HEAP=y +CONFIG_DRM_VGEM=y
tools/testing/selftests/android/ion/config deleted +0 -5
@@ -1,5 +0,0 @@ -CONFIG_ANDROID=y -CONFIG_STAGING=y -CONFIG_ION=y -CONFIG_ION_SYSTEM_HEAP=y -CONFIG_DRM_VGEM=y
Greg Kroah-Hartman
maintainerPATCH 67/135 selftests: kselftest: Remove outdated comment
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thiago Jung Bauermann <[email protected]>
[ Upstream commit c31d02d1290e1e82a08015199e408228e152991f ]
Commit 3c07aaef6598 ("selftests: kselftest: change KSFT_SKIP=4 instead of KSFT_PASS") reverted commit 11867a77eb85 ("selftests: kselftest framework:
change skip exit code to 0") but missed removing the comment which that commit added, so do that now.
--- tools/testing/selftests/kselftest.h | 1 - 1 file changed, 1 deletion(-)
tools/testing/selftests/kselftest.h +0 -1
@@ -19,7 +19,6 @@#define KSFT_FAIL 1#define KSFT_XFAIL 2#define KSFT_XPASS 3 -/* Treat skip as pass */ #define KSFT_SKIP 4/* counters */
Greg Kroah-Hartman
maintainerPATCH 41/135 net: stmmac: Rework coalesce timer and fix multi-queue races
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jose Abreu <[email protected]>
[ Upstream commit 8fce3331702316d4bcfeb0771c09ac75d2192bbc ]
This follows David Miller advice and tries to fix coalesce timer in multi-queue scenarios.
We are now using per-queue coalesce values and per-queue TX timer.
Coalesce timer default values was changed to 1ms and the coalesce frames to 25.
Tested in B2B setup between XGMAC2 and GMAC5.
--- drivers/net/ethernet/stmicro/stmmac/common.h | 4 drivers/net/ethernet/stmicro/stmmac/stmmac.h | 14 + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 234 ++++++++++++---------- include/linux/stmmac.h | 1 4 files changed, 146 insertions(+), 107 deletions(-)
drivers/net/ethernet/stmicro/stmmac/common.h +2 -2
@@ -256,10 +256,10 @@ struct stmmac_safety_stats {#define MAX_DMA_RIWT 0xff#define MIN_DMA_RIWT 0x20/* Tx coalesce parameters */ -#define STMMAC_COAL_TX_TIMER 40000 +#define STMMAC_COAL_TX_TIMER 1000#define STMMAC_MAX_COAL_TX_TICK 100000#define STMMAC_TX_MAX_FRAMES 256 -#define STMMAC_TX_FRAMES 64 +#define STMMAC_TX_FRAMES 25/* Packets types */ enum packets_types {
drivers/net/ethernet/stmicro/stmmac/stmmac.h +12 -2
@@ -48,6 +48,8 @@ struct stmmac_tx_info {/* Frequently used values are kept adjacent for cache effect */ struct stmmac_tx_queue { +u32 tx_count_frames; +struct timer_list txtimer;u32 queue_index;struct stmmac_priv *priv_data;struct dma_extended_desc *dma_etx____cacheline_aligned_in_smp ;
@@ -73,7 +75,14 @@ struct stmmac_rx_queue {u32 rx_zeroc_thresh;dma_addr_t dma_rx_phy;u32 rx_tail_addr; +}; + +struct stmmac_channel {struct napi_struct napi____cacheline_aligned_in_smp ; +struct stmmac_priv *priv_data; +u32 index; +int has_rx; +int has_tx; };struct stmmac_tc_entry {
@@ -109,14 +118,12 @@ struct stmmac_pps_cfg {struct stmmac_priv {/* Frequently used values are kept adjacent for cache effect */ -u32 tx_count_frames;u32 tx_coal_frames;u32 tx_coal_timer;int tx_coalesce;int hwts_tx_en;bool tx_path_in_lpi_mode; -struct timer_list txtimer;bool tso;unsigned int dma_buf_sz;
@@ -137,6 +144,9 @@ struct stmmac_priv {/* TX Queue */ struct stmmac_tx_queue tx_queue[MTL_MAX_TX_QUEUES ]; +/* Generic channel for NAPI */ +struct stmmac_channel channel[STMMAC_CH_MAX ]; +bool oldlink;int speed;int oldduplex;
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +131 -103
402 lines not on this page · raw message
include/linux/stmmac.h +1 -0
@@ -30,6 +30,7 @@#define MTL_MAX_RX_QUEUES 8#define MTL_MAX_TX_QUEUES 8 +#define STMMAC_CH_MAX 8#define STMMAC_RX_COE_NONE 0#define STMMAC_RX_COE_TYPE1 1
Greg Kroah-Hartman
maintainerPATCH 68/135 ASoC: max98373: Added 10ms sleep after amp software reset
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryan Lee <[email protected]>
[ Upstream commit ca917f9fe1a0fab3dde41bba4bbd173c5a3c5805 ]
--- sound/soc/codecs/max98373.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/codecs/max98373.c +2 -0
@@ -729,6 +729,7 @@ static int max98373_probe(struct snd_soc/* Software Reset */ regmap_write (max98373->regmap,MAX98373_R2000_SW_RESET ,MAX98373_SOFT_RESET ); +usleep_range (10000 ,11000 );/* IV default slot configuration */ regmap_write(max98373->regmap,
@@ -817,6 +818,7 @@ static int max98373_resume(struct deviceregmap_write (max98373->regmap,MAX98373_R2000_SW_RESET ,MAX98373_SOFT_RESET ); +usleep_range (10000 ,11000 );regcache_cache_only (max98373->regmap, false);regcache_sync (max98373->regmap);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 69/135 ASoC: wm8804: Add ACPI support
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre-Louis Bossart <[email protected]>
[ Upstream commit 960cdd50ca9fdfeb82c2757107bcb7f93c8d7d41 ]
HID made of either Wolfson/CirrusLogic PCI ID + 8804 identifier.
This helps enumerate the HifiBerry Digi+ HAT boards on the Up2 platform.
The scripts at https://github.com/thesofproject/acpi-scripts can be used to add the ACPI initrd overlays.
--- sound/soc/codecs/wm8804-i2c.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
sound/soc/codecs/wm8804-i2c.c +14 -1
@@ -13,6 +13,7 @@#include <linux/init.h> #include <linux/module.h> #include <linux/i2c.h> +#include <linux/acpi.h> #include "wm8804.h"
@@ -40,17 +41,29 @@ static const struct i2c_device_id wm8804 };MODULE_DEVICE_TABLE (i2c, wm8804_i2c_id); +#if defined(CONFIG_OF )static const struct of_device_id wm8804_of_match[] = { { .compatible ="wlf,wm8804" , }, { } };MODULE_DEVICE_TABLE (of, wm8804_of_match); +#endif + +#ifdef CONFIG_ACPI +static const struct acpi_device_id wm8804_acpi_match[] = { + {"1AEC8804" ,0 },/* Wolfson PCI ID + part ID */ + {"10138804" ,0 },/* Cirrus Logic PCI ID + part ID */ + { }, +}; +MODULE_DEVICE_TABLE (acpi, wm8804_acpi_match); +#endif static struct i2c_driver wm8804_i2c_driver = { .driver = { .name ="wm8804" , .pm = &wm8804_pm, - .of_match_table = wm8804_of_match, + .of_match_table =of_match_ptr (wm8804_of_match), + .acpi_match_table =ACPI_PTR (wm8804_acpi_match), }, .probe = wm8804_i2c_probe, .remove = wm8804_i2c_remove,
Greg Kroah-Hartman
maintainerPATCH 70/135 ASoC: sigmadsp: safeload should not have lower byte limit
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Danny Smith <[email protected]>
[ Upstream commit 5ea752c6efdf5aa8a57aed816d453a8f479f1b0a ]
Fixed range in safeload conditional to allow safeload to up to 20 bytes, without a lower limit.
--- sound/soc/codecs/sigmadsp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
sound/soc/codecs/sigmadsp.c +1 -2
@@ -117,8 +117,7 @@ static int sigmadsp_ctrl_write(struct si struct sigmadsp_control *ctrl, void *data) {/* safeload loads up to 20 bytes in a atomic operation */ -if (ctrl->num_bytes >4 && ctrl->num_bytes <=20 && sigmadsp->ops && - sigmadsp->ops->safeload) +if (ctrl->num_bytes <=20 && sigmadsp->ops && sigmadsp->ops->safeload)return sigmadsp->ops->safeload (sigmadsp, ctrl->addr, data, ctrl->num_bytes);else
Greg Kroah-Hartman
maintainerPATCH 71/135 ASoC: q6routing: initialize data correctly
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
[ Upstream commit 7aa09ff24301535491cd4de1b93107ee91449a12 ]
Some of the router data fields are left as default zeros which are valid dai ids, so initialize these to invalid value of -1.
Without intializing these correctly get_session_from_id() can return incorrect session resulting in not closing the opened copp and messing up with the copp ref count.
--- sound/soc/qcom/qdsp6/q6routing.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
sound/soc/qcom/qdsp6/q6routing.c +3 -1
@@ -933,8 +933,10 @@ static int msm_routing_probe(struct snd_ {int i; -for (i =0 ; i <MAX_SESSIONS ; i++) +for (i =0 ; i <MAX_SESSIONS ; i++) { routing_data->sessions[i].port_id =-1 ; + routing_data->sessions[i].fedai_id =-1 ; + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 72/135 selftests: add headers_install to lib.mk
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anders Roxell <[email protected]>
[ Upstream commit b2d35fa5fc80c27e868e393dcab4c94a0d71737f ]
If the kernel headers aren't installed we can't build all the tests. Add a new make target rule 'khdr' in the file lib.mk to generate the kernel headers and that gets include for every test-dir Makefile that includes lib.mk If the testdir in turn have its own sub-dirs the top_srcdir needs to be set to the linux-rootdir to be able to generate the kernel headers.
--- Makefile | 14 +------------- scripts/subarch.include | 13 +++++++++++++ tools/testing/selftests/android/Makefile | 2 +- tools/testing/selftests/android/ion/Makefile | 2 ++ tools/testing/selftests/futex/functional/Makefile | 1 + tools/testing/selftests/gpio/Makefile | 7 ++----- tools/testing/selftests/kvm/Makefile | 7 ++----- tools/testing/selftests/lib.mk | 12 ++++++++++++ tools/testing/selftests/net/Makefile | 1 + tools/testing/selftests/networking/timestamping/Makefile | 1 + tools/testing/selftests/vm/Makefile | 4 ---- 11 files changed, 36 insertions(+), 28 deletions(-) create mode 100644 scripts/subarch.include
Makefile +1 -13
@@ -298,19 +298,7 @@ KERNELRELEASE = $(shell cat include/conf KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION) export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION -# SUBARCH tells the usermode build what the underlying arch is. That is set -# first, and if a usermode build is happening, the "ARCH=um" on the command -# line overrides the setting of ARCH below. If a native build is happening, -# then ARCH is assigned, getting whatever value it gets normally, and -# SUBARCH is subsequently ignored. - -SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ - -e s/sun4u/sparc64/ \ - -e s/arm.*/arm/ -e s/sa110/arm/ \ - -e s/s390x/s390/ -e s/parisc64/parisc/ \ - -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ - -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \ - -e s/riscv.*/riscv/) +include scripts/subarch.include # Cross compiling and selecting different set of gcc/bin-utils # ---------------------------------------------------------------------------
scripts/subarch.include new file +13 -0
@@ -0,0 +1,13 @@ +# SUBARCH tells the usermode build what the underlying arch is. That is set +# first, and if a usermode build is happening, the "ARCH=um" on the command +# line overrides the setting of ARCH below. If a native build is happening, +# then ARCH is assigned, getting whatever value it gets normally, and +# SUBARCH is subsequently ignored. + +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ + -e s/sun4u/sparc64/ \ + -e s/arm.*/arm/ -e s/sa110/arm/ \ + -e s/s390x/s390/ -e s/parisc64/parisc/ \ + -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ + -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \ + -e s/riscv.*/riscv/)
tools/testing/selftests/android/Makefile +1 -1
@@ -6,7 +6,7 @@ TEST_PROGS := run.sh include ../lib.mk -all: +all: khdr @for DIR in $(SUBDIRS); do \ BUILD_TARGET=$(OUTPUT)/$$DIR; \ mkdir $$BUILD_TARGET -p; \
tools/testing/selftests/android/ion/Makefile +2 -0
@@ -10,6 +10,8 @@ $(TEST_GEN_FILES): ipcsocket.c ionutils. TEST_PROGS := ion_test.sh +KSFT_KHDR_INSTALL := 1 +top_srcdir = ../../../../.. include ../../lib.mk $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
tools/testing/selftests/futex/functional/Makefile +1 -0
@@ -18,6 +18,7 @@ TEST_GEN_FILES := \ TEST_PROGS := run.sh +top_srcdir = ../../../../.. include ../../lib.mk $(TEST_GEN_FILES): $(HEADERS)
tools/testing/selftests/gpio/Makefile +2 -5
@@ -21,11 +21,8 @@ endef CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ LDLIBS += -lmount -I/usr/include/libmount -$(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h +$(BINARIES):| khdr +$(BINARIES): ../../../gpio/gpio-utils.o ../../../gpio/gpio-utils.o: make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio - -../../../../usr/include/linux/gpio.h: - make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell pwd)/../../../../usr/ -
tools/testing/selftests/kvm/Makefile +2 -5
@@ -32,9 +32,6 @@ $(LIBKVM_OBJ): $(OUTPUT)/%.o: %.c $(OUTPUT)/libkvm.a: $(LIBKVM_OBJ) $(AR) crs $@ $^ -$(LINUX_HDR_PATH): - make -C $(top_srcdir) headers_install - -all: $(STATIC_LIBS) $(LINUX_HDR_PATH) +all: $(STATIC_LIBS) $(TEST_GEN_PROGS): $(STATIC_LIBS) -$(TEST_GEN_PROGS) $(LIBKVM_OBJ): | $(LINUX_HDR_PATH) +$(STATIC_LIBS):| khdr
tools/testing/selftests/lib.mk +12 -0
@@ -16,8 +16,20 @@ TEST_GEN_PROGS := $(patsubst %,$(OUTPUT) TEST_GEN_PROGS_EXTENDED := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_PROGS_EXTENDED)) TEST_GEN_FILES := $(patsubst %,$(OUTPUT)/%,$(TEST_GEN_FILES)) +top_srcdir ?= ../../../.. +include $(top_srcdir)/scripts/subarch.include +ARCH ?= $(SUBARCH) + all: $(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED) $(TEST_GEN_FILES) +.PHONY: khdr +khdr: + make ARCH=$(ARCH) -C $(top_srcdir) headers_install + +ifdef KSFT_KHDR_INSTALL +$(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED) $(TEST_GEN_FILES):| khdr +endif + .ONESHELL: define RUN_TEST_PRINT_RESULT TEST_HDR_MSG="selftests: "`basename $$PWD`:" $$BASENAME_TEST"; \
tools/testing/selftests/net/Makefile +1 -0
@@ -15,6 +15,7 @@ TEST_GEN_FILES += udpgso udpgso_bench_tx TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict +KSFT_KHDR_INSTALL := 1 include ../lib.mk $(OUTPUT)/reuseport_bpf_numa: LDFLAGS += -lnuma
tools/testing/selftests/networking/timestamping/Makefile +1 -0
@@ -5,6 +5,7 @@ TEST_PROGS := hwtstamp_config rxtimestam all: $(TEST_PROGS) +top_srcdir = ../../../../.. include ../../lib.mk clean:
tools/testing/selftests/vm/Makefile +0 -4
@@ -25,10 +25,6 @@ TEST_PROGS := run_vmtests include ../lib.mk -$(OUTPUT)/userfaultfd: ../../../../usr/include/linux/kernel.h $(OUTPUT)/userfaultfd: LDLIBS += -lpthread $(OUTPUT)/mlock-random-test: LDLIBS += -lcap - -../../../../usr/include/linux/kernel.h: - make -C ../../../.. headers_install
Greg Kroah-Hartman
maintainerPATCH 74/135 selftests: memory-hotplug: add required configs
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lei Yang <[email protected]>
[ Upstream commit 4d85af102a66ee6aeefa596f273169e77fb2b48e ]
add CONFIG_MEMORY_HOTREMOVE=y in config
without this config, /sys/devices/system/memory/memory*/removable always return 0, I endup getting an early skip during test
--- tools/testing/selftests/memory-hotplug/config | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/memory-hotplug/config +1 -0
@@ -2,3 +2,4 @@ CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y CONFIG_NOTIFIER_ERROR_INJECTION=y CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=m +CONFIG_MEMORY_HOTREMOVE=y
Greg Kroah-Hartman
maintainerPATCH 75/135 ASoC: rsnd: adg: care clock-frequency size
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuninori Morimoto <[email protected]>
[ Upstream commit 69235ccf491d2e26aefd465c0d3ccd1e3b2a9a9c ]
ADG has buffer over flow bug if DT has more than 3 clock-frequency. This patch fixup this issue, and uses first 2 values.
clock-frequency = <x y>; /* this is OK */
clock-frequency = <x y z>; /* this is NG */
--- sound/soc/sh/rcar/adg.c | 5 +++++ 1 file changed, 5 insertions(+)
sound/soc/sh/rcar/adg.c +5 -0
@@ -465,6 +465,11 @@ static void rsnd_adg_get_clkout(struct r goto rsnd_adg_get_clkout_end; req_size = prop->length /sizeof (u32); +if (req_size >REQ_SIZE ) { +dev_err (dev, +"too many clock-frequency, use top %d\n" ,REQ_SIZE ); + req_size =REQ_SIZE ; + }of_property_read_u32_array (np,"clock-frequency" , req_rate, req_size); req_48kHz_rate =0 ;
Greg Kroah-Hartman
maintainerPATCH 76/135 ASoC: rsnd: dont fallback to PIO mode when -EPROBE_DEFER
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuninori Morimoto <[email protected]>
[ Upstream commit 6c92d5a2744e27619a8fcc9d74b91ee9f1cdebd1 ]
Current rsnd driver will fallback to PIO mode if it can't get DMA handler. But, DMA might return -EPROBE_DEFER when probe timing. This driver always fallback to PIO mode especially from commit ac6bbf0cdf4206c ("iommu: Remove IOMMU_OF_DECLARE") because of this reason.
The DMA driver will be probed later, but sound driver might be probed as PIO mode in such case. This patch fixup this issue. Then, -EPROBE_DEFER is not error. Thus, let's don't indicate error message in such case.
And it needs to call rsnd_adg_remove() individually if probe failed, because it registers clk which should be unregister.
Maybe PIO fallback feature itself is not needed,
but let's keep it so far.
--- sound/soc/sh/rcar/core.c | 10 +++++++++- sound/soc/sh/rcar/dma.c | 4 ++++ 2 files changed, 13 insertions(+), 1 deletion(-)
sound/soc/sh/rcar/core.c +9 -1
@@ -482,7 +482,7 @@ static int rsnd_status_update(u32 *statu (func_call && (mod)->ops->fn) ? #fn : ""); \ if (func_call && (mod)->ops->fn) \ tmp = (mod)->ops->fn(mod, io, param); \ - if (tmp) \ + if (tmp && (tmp != -EPROBE_DEFER)) \ dev_err(dev, "%s[%d] : %s error %d\n", \ rsnd_mod_name(mod), rsnd_mod_id(mod), \ #fn, tmp); \
@@ -1550,6 +1550,14 @@ exit_snd_probe:rsnd_dai_call (remove, &rdai->capture, priv); } +/* +* adg is very special mod which can't use rsnd_dai_call(remove), +* and it registers ADG clock on probe. +* It should be unregister if probe failed. +* Mainly it is assuming -EPROBE_DEFER case +*/ +rsnd_adg_remove (priv); +return ret; }
sound/soc/sh/rcar/dma.c +4 -0
@@ -244,6 +244,10 @@ static int rsnd_dmaen_attach(struct rsnd/* try to get DMAEngine channel */ chan =rsnd_dmaen_request_channel (io, mod_from, mod_to);if (IS_ERR_OR_NULL (chan)) { +/* Let's follow when -EPROBE_DEFER case */ +if (PTR_ERR (chan) == -EPROBE_DEFER ) +return PTR_ERR (chan); +/* * DMA failed. try to PIO mode * see
Greg Kroah-Hartman
maintainerPATCH 77/135 hwmon: (nct6775) Fix access to fan pulse registers
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit c793279c77035053e67937f5743c6ebfc303e7c5 ]
Not all fans have a fan pulse register. This can result in reading beyond the end of REG_FAN_PULSES and FAN_PULSE_SHIFT arrays, and was reported by smatch as possible error.
1672 for (i = 0; i < ARRAY_SIZE(data->rpm); i++) {
^^^^^^^^^^^^^^^^^^^^^^^^ This is a 7 element array.
...
1685 data->fan_pulses[i] =
1686 (nct6775_read_value(data, data->REG_FAN_PULSES[i])
1687 >> data->FAN_PULSE_SHIFT[i]) & 0x03;
^^^^^^^^^^^^^^^^^^^^^^^^ FAN_PULSE_SHIFT is either 5 or 6 elements.
To fix the problem, we have to ensure that all REG_FAN_PULSES and FAN_PULSE_SHIFT have the appropriate length, and that REG_FAN_PULSES is only read if the register actually exists.
--- drivers/hwmon/nct6775.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-)
drivers/hwmon/nct6775.c +16 -11
@@ -299,8 +299,9 @@ static const u16 NCT6775_REG_PWM_READ[]static const u16 NCT6775_REG_FAN [] = {0x630 ,0x632 ,0x634 ,0x636 ,0x638 };static const u16 NCT6775_REG_FAN_MIN [] = {0x3b ,0x3c ,0x3d }; -static const u16 NCT6775_REG_FAN_PULSES [] = {0x641 ,0x642 ,0x643 ,0x644 ,0 }; -static const u16 NCT6775_FAN_PULSE_SHIFT [] = {0 ,0 ,0 ,0 ,0 ,0 }; +static const u16 NCT6775_REG_FAN_PULSES [NUM_FAN ] = { +0x641 ,0x642 ,0x643 ,0x644 }; +static const u16 NCT6775_FAN_PULSE_SHIFT [NUM_FAN ] = { };static const u16 NCT6775_REG_TEMP [] = {0x27 ,0x150 ,0x250 ,0x62b ,0x62c ,0x62d };
@@ -425,8 +426,8 @@ static const u8 NCT6776_PWM_MODE_MASK[]static const u16 NCT6776_REG_FAN_MIN [] = {0x63a ,0x63c ,0x63e ,0x640 ,0x642 ,0x64a ,0x64c }; -static const u16 NCT6776_REG_FAN_PULSES [] = { -0x644 ,0x645 ,0x646 ,0x647 ,0x648 ,0x649 ,0 }; +static const u16 NCT6776_REG_FAN_PULSES [NUM_FAN ] = { +0x644 ,0x645 ,0x646 ,0x647 ,0x648 ,0x649 };static const u16 NCT6776_REG_WEIGHT_DUTY_BASE [] = {0x13e ,0x23e ,0x33e ,0x83e ,0x93e ,0xa3e };
@@ -502,8 +503,8 @@ static const s8 NCT6779_BEEP_BITS[] = {static const u16 NCT6779_REG_FAN [] = {0x4b0 ,0x4b2 ,0x4b4 ,0x4b6 ,0x4b8 ,0x4ba ,0x660 }; -static const u16 NCT6779_REG_FAN_PULSES [] = { -0x644 ,0x645 ,0x646 ,0x647 ,0x648 ,0x649 ,0 }; +static const u16 NCT6779_REG_FAN_PULSES [NUM_FAN ] = { +0x644 ,0x645 ,0x646 ,0x647 ,0x648 ,0x649 };static const u16 NCT6779_REG_CRITICAL_PWM_ENABLE [] = {0x136 ,0x236 ,0x336 ,0x836 ,0x936 ,0xa36 ,0xb36 };
@@ -779,8 +780,8 @@ static const u16 NCT6106_REG_TEMP_CONFIGstatic const u16 NCT6106_REG_FAN [] = {0x20 ,0x22 ,0x24 };static const u16 NCT6106_REG_FAN_MIN [] = {0xe0 ,0xe2 ,0xe4 }; -static const u16 NCT6106_REG_FAN_PULSES [] = {0xf6 ,0xf6 ,0xf6 ,0 ,0 }; -static const u16 NCT6106_FAN_PULSE_SHIFT [] = {0 ,2 ,4 ,0 ,0 }; +static const u16 NCT6106_REG_FAN_PULSES [] = {0xf6 ,0xf6 ,0xf6 }; +static const u16 NCT6106_FAN_PULSE_SHIFT [] = {0 ,2 ,4 };static const u8 NCT6106_REG_PWM_MODE [] = {0xf3 ,0xf3 ,0xf3 };static const u8 NCT6106_PWM_MODE_MASK [] = {0x01 ,0x02 ,0x04 };
@@ -1682,9 +1683,13 @@ static struct nct6775_data *nct6775_updaif (data->has_fan_min &BIT (i)) data->fan_min[i] =nct6775_read_value (data, data->REG_FAN_MIN[i]); - data->fan_pulses[i] = - (nct6775_read_value (data, data->REG_FAN_PULSES[i]) - >> data->FAN_PULSE_SHIFT[i]) &0x03 ; + +if (data->REG_FAN_PULSES[i]) { + data->fan_pulses[i] = + (nct6775_read_value (data, + data->REG_FAN_PULSES[i]) + >> data->FAN_PULSE_SHIFT[i]) &0x03 ; + }nct6775_select_fan_div (dev, data, i, reg); }
Greg Kroah-Hartman
maintainerPATCH 43/135 bnxt_en: dont try to offload VLAN modify action
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Davide Caratti <[email protected]>
[ Upstream commit 8c6ec3613e7b0aade20a3196169c0bab32ed3e3f ]
bnxt offload code currently supports only 'push' and 'pop' operation: let .ndo_setup_tc() return -EOPNOTSUPP if VLAN 'modify' action is configured.
--- drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c +14 -6
@@ -75,17 +75,23 @@ static int bnxt_tc_parse_redir(struct bnreturn 0 ; } -static void bnxt_tc_parse_vlan (struct bnxt *bp, -struct bnxt_tc_actions *actions, -const struct tc_action *tc_act) +static int bnxt_tc_parse_vlan (struct bnxt *bp, +struct bnxt_tc_actions *actions, +const struct tc_action *tc_act) { -if (tcf_vlan_action (tc_act) ==TCA_VLAN_ACT_POP ) { +switch (tcf_vlan_action (tc_act)) { +case TCA_VLAN_ACT_POP : actions->flags |=BNXT_TC_ACTION_FLAG_POP_VLAN ; - }else if (tcf_vlan_action (tc_act) ==TCA_VLAN_ACT_PUSH ) { +break ; +case TCA_VLAN_ACT_PUSH : actions->flags |=BNXT_TC_ACTION_FLAG_PUSH_VLAN ; actions->push_vlan_tci =htons (tcf_vlan_push_vid (tc_act)); actions->push_vlan_tpid =tcf_vlan_push_proto (tc_act); +break ; +default : +return -EOPNOTSUPP ; } +return 0 ; } static int bnxt_tc_parse_tunnel_set(struct bnxt *bp,
@@ -136,7 +142,9 @@ static int bnxt_tc_parse_actions(struct/* Push/pop VLAN */ if (is_tcf_vlan (tc_act)) { -bnxt_tc_parse_vlan (bp, actions, tc_act); + rc =bnxt_tc_parse_vlan (bp, actions, tc_act); +if (rc) +return rc;continue ; }
Greg Kroah-Hartman
maintainerPATCH 44/135 net-ethtool: ETHTOOL_GUFO did not and should not require CAP_NET_ADMIN
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Maciej Żenczykowski" <[email protected]>
[ Upstream commit 474ff2600889e16280dbc6ada8bfecb216169a70 ]
So it should not fail with EPERM even though it is no longer implemented...
This is a fix for:
(userns)$ egrep ^Cap /proc/self/status
CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000003fffffffff
(userns)$ tcpdump -i usb_rndis0
tcpdump: WARNING: usb_rndis0: SIOCETHTOOL(ETHTOOL_GUFO) ioctl failed: Operation not permitted
Warning: Kernel filter failed: Bad file descriptor
tcpdump: can't remove kernel filter: Bad file descriptor
With this change it returns EOPNOTSUPP instead of EPERM.
See also https://github.com/the-tcpdump-group/libpcap/issues/689
--- net/core/ethtool.c | 1 + 1 file changed, 1 insertion(+)
net/core/ethtool.c +1 -0
@@ -2623,6 +2623,7 @@ int dev_ethtool(struct net *net, structcase ETHTOOL_GPHYSTATS :case ETHTOOL_GTSO :case ETHTOOL_GPERMADDR : +case ETHTOOL_GUFO :case ETHTOOL_GGSO :case ETHTOOL_GGRO :case ETHTOOL_GFLAGS :
Greg Kroah-Hartman
maintainerPATCH 45/135 net: phy: phylink: fix SFP interface autodetection
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baruch Siach <[email protected]>
[ Upstream commit 7e4183752735deb7543e179a44f4f4b44917cd6f ]
When connecting SFP PHY to phylink use the detected interface. Otherwise, the link fails to come up when the configured 'phy-mode' differs from the SFP detected mode.
Move most of phylink_connect_phy() into __phylink_connect_phy(), and leave phylink_connect_phy() as a wrapper. phylink_sfp_connect_phy() can now pass the SFP detected PHY interface to __phylink_connect_phy().
This fixes 1GB SFP module link up on eth3 of the Macchiatobin board that is configured in the DT to "2500base-x" phy-mode.
--- drivers/net/phy/phylink.c | 48 ++++++++++++++++++++++++++-------------------- 1 file changed, 28 insertions(+), 20 deletions(-)
drivers/net/phy/phylink.c +28 -20
@@ -717,6 +717,30 @@ static int phylink_bringup_phy(struct phreturn 0 ; } +static int __phylink_connect_phy (struct phylink *pl,struct phy_device *phy, +phy_interface_t interface) +{ +int ret; + +if (WARN_ON (pl->link_an_mode ==MLO_AN_FIXED || + (pl->link_an_mode ==MLO_AN_INBAND && +phy_interface_mode_is_8023z (interface)))) +return -EINVAL ; + +if (pl->phydev) +return -EBUSY ; + + ret =phy_attach_direct (pl->netdev, phy,0 , interface); +if (ret) +return ret; + + ret =phylink_bringup_phy (pl, phy); +if (ret) +phy_detach (phy); + +return ret; +} +/** * phylink_connect_phy() - connect a PHY to the phylink instance * @pl: a pointer to a &struct phylink returned from phylink_create()
@@ -734,31 +758,13 @@ static int phylink_bringup_phy(struct ph*/ int phylink_connect_phy (struct phylink *pl,struct phy_device *phy) { -int ret; - -if (WARN_ON (pl->link_an_mode ==MLO_AN_FIXED || - (pl->link_an_mode ==MLO_AN_INBAND && -phy_interface_mode_is_8023z (pl->link_interface)))) -return -EINVAL ; - -if (pl->phydev) -return -EBUSY ; -/* Use PHY device/driver interface */ if (pl->link_interface ==PHY_INTERFACE_MODE_NA ) { pl->link_interface = phy->interface; pl->link_config.interface = pl->link_interface; } - ret =phy_attach_direct (pl->netdev, phy,0 , pl->link_interface); -if (ret) -return ret; - - ret =phylink_bringup_phy (pl, phy); -if (ret) -phy_detach (phy); - -return ret; +return __phylink_connect_phy (pl, phy, pl->link_interface); }EXPORT_SYMBOL_GPL (phylink_connect_phy);
@@ -1672,7 +1678,9 @@ static void phylink_sfp_link_up(void *upstatic int phylink_sfp_connect_phy (void *upstream,struct phy_device *phy) { -return phylink_connect_phy (upstream, phy); +struct phylink *pl = upstream; + +return __phylink_connect_phy (upstream, phy, pl->link_config.interface); }static void phylink_sfp_disconnect_phy (void *upstream)
Greg Kroah-Hartman
maintainerPATCH 46/135 sfp: fix oops with ethtool -m
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
[ Upstream commit 126d6848ef13958e1cb959e96c21d19bc498ade9 ]
If a network interface is created prior to the SFP socket being available, ethtool can request module information. This unfortunately leads to an oops:
Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = (ptrval) [00000008] *pgd=7c400831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138 Hardware name: Broadcom Northstar Plus SoC PC is at sfp_get_module_info+0x8/0x10 LR is at dev_ethtool+0x218c/0x2afc
Fix this by not filling in the network device's SFP bus pointer until SFP is fully bound, thereby avoiding the core calling into the SFP bus code.
--- drivers/net/phy/sfp-bus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/phy/sfp-bus.c +2 -2
@@ -349,6 +349,7 @@ static int sfp_register_bus(struct sfp_b }if (bus->started) bus->socket_ops->start (bus->sfp); + bus->netdev->sfp_bus = bus; bus->registered = true;return 0 ; }
@@ -357,6 +358,7 @@ static void sfp_unregister_bus(struct sf {const struct sfp_upstream_ops *ops = bus->upstream_ops; + bus->netdev->sfp_bus =NULL ;if (bus->registered) {if (bus->started) bus->socket_ops->stop (bus->sfp);
@@ -438,7 +440,6 @@ static void sfp_upstream_clear(struct sf { bus->upstream_ops =NULL ; bus->upstream =NULL ; - bus->netdev->sfp_bus =NULL ; bus->netdev =NULL ; }
@@ -467,7 +468,6 @@ struct sfp_bus *sfp_register_upstream(st bus->upstream_ops = ops; bus->upstream = upstream; bus->netdev = ndev; - ndev->sfp_bus = bus;if (bus->sfp) { ret =sfp_register_bus (bus);
Greg Kroah-Hartman
maintainerPATCH 47/135 tcp/dccp: fix lockdep issue when SYN is backlogged
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 1ad98e9d1bdf4724c0a8532fabd84bf3c457c2bc ]
In normal SYN processing, packets are handled without listener lock and in RCU protected ingress path.
But syzkaller is known to be able to trick us and SYN packets might be processed in process context, after being queued into socket backlog.
In commit 06f877d613be ("tcp/dccp: fix other lockdep splats accessing ireq_opt") I made a very stupid fix, that happened to work mostly because of the regular path being RCU protected.
Really the thing protecting ireq->ireq_opt is RCU read lock, and the pseudo request refcnt is not relevant.
This patch extends what I did in commit 449809a66c1d ("tcp/dccp:
block BH for SYN processing") by adding an extra rcu_read_{lock|unlock} pair in the paths that might be taken when processing SYN from socket backlog (thus possibly in process context)
--- include/net/inet_sock.h | 3 +-- net/dccp/input.c | 4 +++- net/ipv4/tcp_input.c | 4 +++- 3 files changed, 7 insertions(+), 4 deletions(-)
include/net/inet_sock.h +1 -2
@@ -132,8 +132,7 @@ static inline int inet_request_bound_devstatic inline struct ip_options_rcu *ireq_opt_deref (const struct inet_request_sock *ireq) { -return rcu_dereference_check (ireq->ireq_opt, -refcount_read (&ireq->req.rsk_refcnt) >0 ); +return rcu_dereference (ireq->ireq_opt); }struct inet_cork {
net/dccp/input.c +3 -1
@@ -606,11 +606,13 @@ int dccp_rcv_state_process(struct sock *if (sk->sk_state ==DCCP_LISTEN ) {if (dh->dccph_type ==DCCP_PKT_REQUEST ) {/* It is possible that we process SYN packets from backlog, -* so we need to make sure to disable BH right there. +* so we need to make sure to disable BH and RCU right there. */ +rcu_read_lock ();local_bh_disable (); acceptable =inet_csk (sk)->icsk_af_ops->conn_request (sk, skb) >=0 ;local_bh_enable (); +rcu_read_unlock ();if (!acceptable)return 1 ;consume_skb (skb);
net/ipv4/tcp_input.c +3 -1
@@ -5976,11 +5976,13 @@ int tcp_rcv_state_process(struct sock *sif (th->fin) goto discard;/* It is possible that we process SYN packets from backlog, -* so we need to make sure to disable BH right there. +* so we need to make sure to disable BH and RCU right there. */ +rcu_read_lock ();local_bh_disable (); acceptable = icsk->icsk_af_ops->conn_request (sk, skb) >=0 ;local_bh_enable (); +rcu_read_unlock ();if (!acceptable)return 1 ;
Greg Kroah-Hartman
maintainerPATCH 90/135 sound: dont call skl_init_chip() to reset intel skl soc
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Zhao <[email protected]>
[ Upstream commit 75383f8d39d4c0fb96083dd460b7b139fbdac492 ]
Internally, skl_init_chip() calls snd_hdac_bus_init_chip() which
1) sets bus->chip_init to prevent multiple entrances before device is stopped; 2) enables interrupt.
We shouldn't use it for the purpose of resetting device only because
1) when we really want to initialize device, we won't be able to do so; 2) we are ready to handle interrupt yet, and kernel crashes when interrupt comes in.
Rename azx_reset() to snd_hdac_bus_reset_link(), and use it to reset device properly.
--- include/sound/hdaudio.h | 1 + sound/hda/hdac_controller.c | 7 ++++--- sound/soc/intel/skylake/skl.c | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-)
include/sound/hdaudio.h +1 -0
@@ -355,6 +355,7 @@ void snd_hdac_bus_init_cmd_io(struct hdavoid snd_hdac_bus_stop_cmd_io (struct hdac_bus *bus);void snd_hdac_bus_enter_link_reset (struct hdac_bus *bus);void snd_hdac_bus_exit_link_reset (struct hdac_bus *bus); +int snd_hdac_bus_reset_link (struct hdac_bus *bus,bool full_reset);void snd_hdac_bus_update_rirb (struct hdac_bus *bus); int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status,
sound/hda/hdac_controller.c +4 -3
@@ -385,7 +385,7 @@ void snd_hdac_bus_exit_link_reset(structEXPORT_SYMBOL_GPL (snd_hdac_bus_exit_link_reset);/* reset codec link */ -static int azx_reset (struct hdac_bus *bus,bool full_reset) +int snd_hdac_bus_reset_link (struct hdac_bus *bus,bool full_reset) {if (!full_reset) goto skip_reset;
@@ -410,7 +410,7 @@ static int azx_reset(struct hdac_bus *bu skip_reset:/* check to see if controller is ready */ if (!snd_hdac_chip_readb (bus,GCTL )) { -dev_dbg (bus->dev,"azx_reset: controller not ready!\n" ); +dev_dbg (bus->dev,"controller not ready!\n" );return -EBUSY ; }
@@ -425,6 +425,7 @@ static int azx_reset(struct hdac_bus *bureturn 0 ; } +EXPORT_SYMBOL_GPL (snd_hdac_bus_reset_link);/* enable interrupts */ static void azx_int_enable (struct hdac_bus *bus)
@@ -479,7 +480,7 @@ bool snd_hdac_bus_init_chip(struct hdac_return false;/* reset controller */ -azx_reset (bus, full_reset); +snd_hdac_bus_reset_link (bus, full_reset);/* clear interrupts */ azx_int_clear (bus);
sound/soc/intel/skylake/skl.c +1 -1
@@ -844,7 +844,7 @@ static int skl_first_init(struct hdac_exreturn -ENXIO ; } -skl_init_chip (bus, true); +snd_hdac_bus_reset_link (bus, true);snd_hdac_bus_parse_capabilities (bus);
Greg Kroah-Hartman
maintainerPATCH 91/135 bpf: btf: Fix end boundary calculation for type section
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin KaFai Lau <[email protected]>
[ Upstream commit 4b1c5d917d34f705096bb7dd8a2bd19b0881970e ]
The end boundary math for type section is incorrect in btf_check_all_metas(). It just happens that hdr->type_off is always 0 for now because there are only two sections (type and string) and string section must be at the end (ensured in btf_parse_str_sec).
However, type_off may not be 0 if a new section would be added later. This patch fixes it.
--- kernel/bpf/btf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/bpf/btf.c +1 -1
@@ -1844,7 +1844,7 @@ static int btf_check_all_metas(struct bt hdr = &btf->hdr; cur = btf->nohdr_data + hdr->type_off; - end = btf->nohdr_data + hdr->type_len; + end = cur + hdr->type_len; env->log_type_id =1 ;while (cur < end) {
Greg Kroah-Hartman
maintainerPATCH 92/135 bpf: use __GFP_COMP while allocating page
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tushar Dave <[email protected]>
[ Upstream commit 4c3d795cb012a378855543a775408fba1ccff6f2 ]
Helper bpg_msg_pull_data() can allocate multiple pages while linearizing multiple scatterlist elements into one shared page. However, if the shared page has size > PAGE_SIZE, using copy_page_to_iter() causes below warning.
e.g.
[ 6367.019832] WARNING: CPU: 2 PID: 7410 at lib/iov_iter.c:825
page_copy_sane.part.8+0x0/0x8
To avoid above warning, use __GFP_COMP while allocating multiple contiguous pages.
--- net/core/filter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/core/filter.c +2 -1
@@ -2334,7 +2334,8 @@ BPF_CALL_4(bpf_msg_pull_data,if (unlikely (bytes_sg_total > copy))return -EINVAL ; - page =alloc_pages (__GFP_NOWARN |GFP_ATOMIC ,get_order (copy)); + page =alloc_pages (__GFP_NOWARN |GFP_ATOMIC | __GFP_COMP, +get_order (copy));if (unlikely (!page))return -ENOMEM ; p =page_address (page);
Greg Kroah-Hartman
maintainerPATCH 94/135 hwmon: (nct6775) Fix RPM output for fan7 on NCT6796D
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit f6de298806d9cbc63a4907bca34a06162b9d7dce ]
fan7 on NCT6796D does not have a fan count register; it only has an RPM register. Switch to using RPM registers to read the fan speed for all chips supporting it to solve the problem for good.
--- drivers/hwmon/nct6775.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/hwmon/nct6775.c +9 -4
@@ -502,7 +502,7 @@ static const s8 NCT6779_BEEP_BITS[] = { 30, 31 }; /* intrusion0, intrusion1 */static const u16 NCT6779_REG_FAN [] = { -0x4b0 ,0x4b2 ,0x4b4 ,0x4b6 ,0x4b8 ,0x4ba ,0x660 }; +0x4c0 ,0x4c2 ,0x4c4 ,0x4c6 ,0x4c8 ,0x4ca ,0x660 };static const u16 NCT6779_REG_FAN_PULSES [NUM_FAN ] = {0x644 ,0x645 ,0x646 ,0x647 ,0x648 ,0x649 };
@@ -924,6 +924,11 @@ static unsigned int fan_from_reg16(u16 rreturn 1350000U / (reg << divreg); } +static unsigned int fan_from_reg_rpm (u16 reg,unsigned int divreg) +{ +return reg; +} +static u16 fan_to_reg (u32 fan,unsigned int divreg) {if (!fan)
@@ -1284,7 +1289,7 @@ static bool is_word_sized(struct nct6775case nct6795:case nct6796:return reg ==0x150 || reg ==0x153 || reg ==0x155 || - ((reg &0xfff0 ) ==0x4b0 && (reg &0x000f ) <0x0b ) || + (reg &0xfff0 ) ==0x4c0 || reg ==0x402 || reg ==0x63a || reg ==0x63c || reg ==0x63e || reg == 0x640 || reg == 0x642 || reg == 0x64a ||
@@ -3868,7 +3873,7 @@ static int nct6775_probe(struct platform data->ALARM_BITS =NCT6779_ALARM_BITS ; data->BEEP_BITS =NCT6779_BEEP_BITS ; - data->fan_from_reg = fan_from_reg13; + data->fan_from_reg = fan_from_reg_rpm; data->fan_from_reg_min = fan_from_reg13; data->target_temp_mask =0xff ; data->tolerance_mask =0x07 ;
@@ -3949,7 +3954,7 @@ static int nct6775_probe(struct platform data->ALARM_BITS =NCT6791_ALARM_BITS ; data->BEEP_BITS =NCT6779_BEEP_BITS ; - data->fan_from_reg = fan_from_reg13; + data->fan_from_reg = fan_from_reg_rpm; data->fan_from_reg_min = fan_from_reg13; data->target_temp_mask =0xff ; data->tolerance_mask =0x07 ;
Greg Kroah-Hartman
maintainerPATCH 96/135 hwmon: (nct6775) Use different register to get fan RPM for fan7
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 55066354285b36ee09dc50e2527f43a97c567177 ]
The documented register to retrieve the fan RPM for fan7 is found to be unreliable at least with NCT6796D revision 3. Let's use register 0x4ce instead. This is undocumented for NCT6796D, but documented for NCT6797D and NCT6798D and known to be working.
--- drivers/hwmon/nct6775.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/nct6775.c +2 -2
@@ -502,7 +502,7 @@ static const s8 NCT6779_BEEP_BITS[] = { 30, 31 }; /* intrusion0, intrusion1 */static const u16 NCT6779_REG_FAN [] = { -0x4c0 ,0x4c2 ,0x4c4 ,0x4c6 ,0x4c8 ,0x4ca ,0x660 }; +0x4c0 ,0x4c2 ,0x4c4 ,0x4c6 ,0x4c8 ,0x4ca ,0x4ce };static const u16 NCT6779_REG_FAN_PULSES [NUM_FAN ] = {0x644 ,0x645 ,0x646 ,0x647 ,0x648 ,0x649 };
@@ -1293,7 +1293,7 @@ static bool is_word_sized(struct nct6775 reg ==0x402 || reg ==0x63a || reg ==0x63c || reg ==0x63e || reg ==0x640 || reg ==0x642 || reg ==0x64a || - reg ==0x64c || reg ==0x660 || + reg ==0x64c || reg ==0x73 || reg ==0x75 || reg ==0x77 || reg ==0x79 || reg ==0x7b || reg ==0x7d ; }
Greg Kroah-Hartman
maintainerPATCH 97/135 net: ethernet: ti: add missing GENERIC_ALLOCATOR dependency
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Corentin Labbe <[email protected]>
[ Upstream commit f025571e96caa95ffc3c1792f762a584893de582 ]
This patch mades TI_DAVINCI_CPDMA select GENERIC_ALLOCATOR. without that, the following sparc64 build failure happen
drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_check_free_tx_desc':
(.text+0x278): undefined reference to gen_pool_avail' drivers/net/ethernet/ti/davinci_cpdma.o: In function cpdma_chan_submit':
(.text+0x340): undefined reference to `gen_pool_alloc'
(.text+0x5c4): undefined reference to gen_pool_free' drivers/net/ethernet/ti/davinci_cpdma.o: In function __cpdma_chan_free':
davinci_cpdma.c:(.text+0x64c): undefined reference to gen_pool_free' drivers/net/ethernet/ti/davinci_cpdma.o: In function cpdma_desc_pool_destroy.isra.6':
davinci_cpdma.c:(.text+0x17ac): undefined reference to gen_pool_size' davinci_cpdma.c:(.text+0x17b8): undefined reference to gen_pool_avail' davinci_cpdma.c:(.text+0x1824): undefined reference to gen_pool_size' davinci_cpdma.c:(.text+0x1830): undefined reference to gen_pool_avail' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_ctlr_create':
(.text+0x19f8): undefined reference to devm_gen_pool_create' (.text+0x1a90): undefined reference to gen_pool_add_virt' Makefile:1011: recipe for target 'vmlinux' failed
--- drivers/net/ethernet/ti/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/ti/Kconfig +1 -0
@@ -41,6 +41,7 @@ config TI_DAVINCI_MDIO config TI_DAVINCI_CPDMA tristate "TI DaVinci CPDMA Support" depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST + select GENERIC_ALLOCATOR ---help--- This driver supports TI's DaVinci CPDMA dma engine.
Greg Kroah-Hartman
maintainerPATCH 81/135 drm/pl111: Make sure of_device_id tables are NULL terminated
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhong jiang <[email protected]>
[ Upstream commit 7eb33224572636248d5b6cfa1a6b2472207be5c4 ]
We prefer to of_device_id tables are NULL terminated. So make vexpress_muxfpga_match is NULL terminated.
--- drivers/gpu/drm/pl111/pl111_vexpress.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/pl111/pl111_vexpress.c +2 -1
@@ -111,7 +111,8 @@ static int vexpress_muxfpga_probe(struct }static const struct of_device_id vexpress_muxfpga_match[] = { - { .compatible ="arm,vexpress-muxfpga" , } + { .compatible ="arm,vexpress-muxfpga" , }, + {} };static struct platform_driver vexpress_muxfpga_driver = {
Greg Kroah-Hartman
maintainerPATCH 99/135 ARM: dts: at91: add new compatibility string for macb on sama5d3
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Ferre <[email protected]>
[ Upstream commit 321cc359d899a8e988f3725d87c18a628e1cc624 ]
We need this new compatibility string as we experienced different behavior for this 10/100Mbits/s macb interface on this particular SoC. Backward compatibility is preserved as we keep the alternative strings.
--- Documentation/devicetree/bindings/net/macb.txt | 1 + arch/arm/boot/dts/sama5d3_emac.dtsi | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/net/macb.txt +1 -0
@@ -10,6 +10,7 @@ Required properties: Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on the Cadence GEM, or the generic form: "cdns,gem". Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 SoCs. + Use "atmel,sama5d3-macb" for the 10/100Mbit IP available on Atmel sama5d3 SoCs. Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs. Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs. Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
arch/arm/boot/dts/sama5d3_emac.dtsi +1 -1
@@ -41,7 +41,7 @@ }; macb1: ethernet@f802c000 { - compatible = "cdns,at91sam9260-macb", "cdns,macb"; + compatible = "atmel,sama5d3-macb", "cdns,at91sam9260-macb", "cdns,macb"; reg = <0xf802c000 0x100>; interrupts = <35 IRQ_TYPE_LEVEL_HIGH 3>; pinctrl-names = "default";
Greg Kroah-Hartman
maintainerPATCH 100/135 PCI: hv: support reporting serial number as slot information
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit a15f2c08c70811f120d99288d81f70d7f3d104f1 ]
The Hyper-V host API for PCI provides a unique "serial number" which can be used as basis for sysfs PCI slot table. This can be useful for cases where userspace wants to find the PCI device based on serial number.
When an SR-IOV NIC is added, the host sends an attach message with serial number. The kernel doesn't use the serial number, but it is useful when doing the same thing in a userspace driver such as the DPDK. By having /sys/bus/pci/slots/N it provides a direct way to find the matching PCI device.
There maybe some cases where serial number is not unique such as when using GPU's. But the PCI slot infrastructure will handle that.
This has a side effect which may also be useful. The common udev network device naming policy uses the slot information (rather than PCI address).
--- drivers/pci/controller/pci-hyperv.c | 37 ++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
drivers/pci/controller/pci-hyperv.c +37 -0
@@ -89,6 +89,9 @@ static enum pci_protocol_version_t pci_p#define STATUS_REVISION_MISMATCH 0xC0000059 +/* space for 32bit serial number as string */ +#define SLOT_NAME_SIZE 11 +/* * Message Types */
@@ -494,6 +497,7 @@ struct hv_pci_dev {struct list_head list_entry;refcount_t refs;enum hv_pcichild_state state; +struct pci_slot *pci_slot;struct pci_function_description desc;bool reported_missing;struct hv_pcibus_device *hbus;
@@ -1457,6 +1461,34 @@ static void prepopulate_bars(struct hv_pspin_unlock_irqrestore (&hbus->device_list_lock, flags); } +/* +* Assign entries in sysfs pci slot directory. +* +* Note that this function does not need to lock the children list +* because it is called from pci_devices_present_work which +* is serialized with hv_eject_device_work because they are on the +* same ordered workqueue. Therefore hbus->children list will not change +* even when pci_create_slot sleeps. +*/ +static void hv_pci_assign_slots (struct hv_pcibus_device *hbus) +{ +struct hv_pci_dev *hpdev; +char name[SLOT_NAME_SIZE ]; +int slot_nr; + +list_for_each_entry (hpdev, &hbus->children, list_entry) { +if (hpdev->pci_slot) +continue ; + + slot_nr =PCI_SLOT (wslot_to_devfn (hpdev->desc.win_slot.slot)); +snprintf (name,SLOT_NAME_SIZE ,"%u" , hpdev->desc.ser); + hpdev->pci_slot =pci_create_slot (hbus->pci_bus, slot_nr, + name,NULL ); +if (!hpdev->pci_slot) +pr_warn ("pci_create slot %s failed\n" , name); + } +} +/** * create_root_hv_pci_bus() - Expose a new root PCI bus * @hbus: Root PCI bus, as understood by this driver
@@ -1480,6 +1512,7 @@ static int create_root_hv_pci_bus(structpci_lock_rescan_remove ();pci_scan_child_bus (hbus->pci_bus);pci_bus_assign_resources (hbus->pci_bus); +hv_pci_assign_slots (hbus);pci_bus_add_devices (hbus->pci_bus);pci_unlock_rescan_remove (); hbus->state = hv_pcibus_installed;
@@ -1742,6 +1775,7 @@ static void pci_devices_present_work(str*/ pci_lock_rescan_remove ();pci_scan_child_bus (hbus->pci_bus); +hv_pci_assign_slots (hbus);pci_unlock_rescan_remove ();break ;
@@ -1858,6 +1892,9 @@ static void hv_eject_device_work(structlist_del (&hpdev->list_entry);spin_unlock_irqrestore (&hpdev->hbus->device_list_lock, flags); +if (hpdev->pci_slot) +pci_destroy_slot (hpdev->pci_slot); +memset (&ctxt,0 ,sizeof (ctxt)); ejct_pkt = (struct pci_eject_response *)&ctxt.pkt.message; ejct_pkt->message_type.type =PCI_EJECTION_COMPLETE ;
Greg Kroah-Hartman
maintainerPATCH 101/135 hv_netvsc: pair VF based on serial number
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit 00d7ddba1143623b31bc2c15d18216e2da031b14 ]
Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++------------------ 2 files changed, 36 insertions(+), 25 deletions(-)
drivers/net/hyperv/netvsc.c +3 -0
@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated; net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial; +netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,
drivers/net/hyperv/netvsc_drv.c +33 -25
79 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 102/135 clk: x86: add "ether_clk" alias for Bay Trail / Cherry Trail
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit b1e3454d39f992e5409cd19f97782185950df6e7 ]
Commit d31fd43c0f9a ("clk: x86: Do not gate clocks enabled by the firmware") causes all unclaimed PMC clocks on Cherry Trail devices to be on all the time, resulting on the device not being able to reach S0i2 or S0i3 when suspended.
The reason for this commit is that on some Bay Trail / Cherry Trail devices the ethernet controller uses pmc_plt_clk_4. This commit adds an "ether_clk" alias, so that the relevant ethernet drivers can try to (optionally) use this, without needing X86 specific code / hacks, thus fixing ethernet on these devices without breaking S0i3 support.
This commit uses clkdev_hw_create() to create the alias, mirroring the code for the already existing "mclk" alias for pmc_plt_clk_3.
--- drivers/clk/x86/clk-pmc-atom.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/clk/x86/clk-pmc-atom.c +11 -0
@@ -55,6 +55,7 @@ struct clk_plt_data {u8 nparents;struct clk_plt *clks[PMC_CLK_NUM ];struct clk_lookup *mclk_lookup; +struct clk_lookup *ether_clk_lookup; };/* Return an index in parent table */
@@ -351,11 +352,20 @@ static int plt_clk_probe(struct platform goto err_unreg_clk_plt; } + data->ether_clk_lookup =clkdev_hw_create (&data->clks[4 ]->hw, +"ether_clk" ,NULL ); +if (!data->ether_clk_lookup) { + err = -ENOMEM ; + goto err_drop_mclk; + } +plt_clk_free_parent_names_loop (parent_names, data->nparents);platform_set_drvdata (pdev, data);return 0 ; +err_drop_mclk: +clkdev_drop (data->mclk_lookup); err_unreg_clk_plt:plt_clk_unregister_loop (data, i);plt_clk_unregister_parents (data);
@@ -369,6 +379,7 @@ static int plt_clk_remove(struct platfor data =platform_get_drvdata (pdev); +clkdev_drop (data->ether_clk_lookup);clkdev_drop (data->mclk_lookup);plt_clk_unregister_loop (data,PMC_CLK_NUM );plt_clk_unregister_parents (data);
Greg Kroah-Hartman
maintainerPATCH 103/135 clk: x86: Stop marking clocks as CLK_IS_CRITICAL
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 648e921888ad96ea3dc922739e96716ad3225d7f ]
Commit d31fd43c0f9a ("clk: x86: Do not gate clocks enabled by the firmware"), which added the code to mark clocks as CLK_IS_CRITICAL, causes all unclaimed PMC clocks on Cherry Trail devices to be on all the time, resulting on the device not being able to reach S0i3 when suspended.
The reason for this commit is that on some Bay Trail / Cherry Trail devices the r8169 ethernet controller uses pmc_plt_clk_4. Now that the clk-pmc-atom driver exports an "ether_clk" alias for pmc_plt_clk_4 and the r8169 driver has been modified to get and enable this clock (if present) the marking of the clocks as CLK_IS_CRITICAL is no longer necessary.
This commit removes the CLK_IS_CRITICAL marking, fixing Cherry Trail devices not being able to reach S0i3 greatly decreasing their battery drain when suspended.
--- drivers/clk/x86/clk-pmc-atom.c | 7 ------- 1 file changed, 7 deletions(-)
drivers/clk/x86/clk-pmc-atom.c +0 -7
@@ -187,13 +187,6 @@ static struct clk_plt *plt_clk_register( pclk->reg = base +PMC_CLK_CTL_OFFSET + id *PMC_CLK_CTL_SIZE ;spin_lock_init (&pclk->lock); -/* -* If the clock was already enabled by the firmware mark it as critical -* to avoid it being gated by the clock framework if no driver owns it. -*/ -if (plt_clk_is_enabled (&pclk->hw)) - init.flags |=CLK_IS_CRITICAL ; - ret =devm_clk_hw_register (&pdev->dev, &pclk->hw);if (ret) { pclk =ERR_PTR (ret);
Greg Kroah-Hartman
maintainerPATCH 104/135 pinctrl: cannonlake: Fix gpio base for GPP-E
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Detheridge <[email protected]>
[ Upstream commit 8e2aac333785f91ff74e219a1e78e6bdc1ef2c41 ]
The gpio base for GPP-E was set incorrectly to 258 instead of 256, preventing the touchpad working on my Tong Fang GK5CN5Z laptop.
--- drivers/pinctrl/intel/pinctrl-cannonlake.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/intel/pinctrl-cannonlake.c +1 -1
@@ -382,7 +382,7 @@ static const struct intel_padgroup cnlh_static const struct intel_padgroup cnlh_community3_gpps[] = {CNL_GPP (0 ,155 ,178 ,192 ),/* GPP_K */ CNL_GPP (1 ,179 ,202 ,224 ),/* GPP_H */ -CNL_GPP (2 ,203 ,215 ,258 ),/* GPP_E */ +CNL_GPP (2 ,203 ,215 ,256 ),/* GPP_E */ CNL_GPP (3 ,216 ,239 ,288 ),/* GPP_F */ CNL_GPP (4 ,240 ,248 ,CNL_NO_GPIO ),/* SPI */ };
Greg Kroah-Hartman
maintainerPATCH 105/135 x86/kvm/lapic: always disable MMIO interface in x2APIC mode
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vitaly Kuznetsov <[email protected]>
[ Upstream commit d1766202779e81d0f2a94c4650a6ba31497d369d ]
When VMX is used with flexpriority disabled (because of no support or if disabled with module parameter) MMIO interface to lAPIC is still available in x2APIC mode while it shouldn't be (kvm-unit-tests):
PASS: apic_disable: Local apic enabled in x2APIC mode
PASS: apic_disable: CPUID.1H:EDX.APIC[bit 9] is set
FAIL: apic_disable: *0xfee00030: 50014
The issue appears because we basically do nothing while switching to x2APIC mode when APIC access page is not used. apic_mmio_{read,write} only check if lAPIC is disabled before proceeding to actual write.
When APIC access is virtualized we correctly manipulate with VMX controls in vmx_set_virtual_apic_mode() and we don't get vmexits from memory writes in x2APIC mode so there's no issue.
Disabling MMIO interface seems to be easy. The question is: what do we do with these reads and writes? If we add apic_x2apic_mode() check to apic_mmio_in_range() and return -EOPNOTSUPP these reads and writes will go to userspace. When lAPIC is in kernel, Qemu uses this interface to inject MSIs only (see kvm_apic_mem_write() in hw/i386/kvm/apic.c). This somehow works with disabled lAPIC but when we're in xAPIC mode we will get a real injected MSI from every write to lAPIC. Not good.
The simplest solution seems to be to just ignore writes to the region and return ~0 for all reads when we're in x2APIC mode. This is what this patch does. However, this approach is inconsistent with what currently happens when flexpriority is enabled: we allocate APIC access page and create KVM memory region so in x2APIC modes all reads and writes go to this pre-allocated page which is, btw, the same for all vCPUs.
--- arch/x86/include/uapi/asm/kvm.h | 1 + arch/x86/kvm/lapic.c | 22 +++++++++++++++++++--- 2 files changed, 20 insertions(+), 3 deletions(-)
arch/x86/include/uapi/asm/kvm.h +1 -0
@@ -377,5 +377,6 @@ struct kvm_sync_regs {#define KVM_X86_QUIRK_LINT0_REENABLED (1 << 0)#define KVM_X86_QUIRK_CD_NW_CLEARED (1 << 1) +#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE (1 << 2)#endif /* _ASM_X86_KVM_H */
arch/x86/kvm/lapic.c +19 -3
@@ -1291,9 +1291,8 @@ EXPORT_SYMBOL_GPL(kvm_lapic_reg_read);static int apic_mmio_in_range (struct kvm_lapic *apic,gpa_t addr) { -return kvm_apic_hw_enabled (apic) && - addr >= apic->base_address && - addr < apic->base_address +LAPIC_MMIO_LENGTH ; +return addr >= apic->base_address && + addr < apic->base_address +LAPIC_MMIO_LENGTH ; } static int apic_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
@@ -1305,6 +1304,15 @@ static int apic_mmio_read(struct kvm_vcpif (!apic_mmio_in_range (apic, address))return -EOPNOTSUPP ; +if (!kvm_apic_hw_enabled (apic) ||apic_x2apic_mode (apic)) { +if (!kvm_check_has_quirk (vcpu->kvm, +KVM_X86_QUIRK_LAPIC_MMIO_HOLE )) +return -EOPNOTSUPP ; + +memset (data,0xff , len); +return 0 ; + } +kvm_lapic_reg_read (apic, offset, len, data);return 0 ;
@@ -1864,6 +1872,14 @@ static int apic_mmio_write(struct kvm_vcif (!apic_mmio_in_range (apic, address))return -EOPNOTSUPP ; +if (!kvm_apic_hw_enabled (apic) ||apic_x2apic_mode (apic)) { +if (!kvm_check_has_quirk (vcpu->kvm, +KVM_X86_QUIRK_LAPIC_MMIO_HOLE )) +return -EOPNOTSUPP ; + +return 0 ; + } +/* * APIC register must be aligned on 128-bits boundary. * 32/64/128 bits registers must be accessed thru 32 bits.
Greg Kroah-Hartman
maintainerPATCH 106/135 drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amber Lin <[email protected]>
[ Upstream commit caaa4c8a6be2a275bd14f2369ee364978ff74704 ]
A wrong register bit was examinated for checking SDMA status so it reports false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct bit.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c +1 -1
@@ -677,7 +677,7 @@ static int kgd_hqd_sdma_destroy(struct kwhile (true) { temp =RREG32 (sdma_base_addr + mmSDMA0_RLC0_CONTEXT_STATUS); -if (temp &SDMA0_STATUS_REG__RB_CMD_IDLE__SHIFT ) +if (temp &SDMA0_RLC0_CONTEXT_STATUS__IDLE_MASK )break ;if (time_after (jiffies, end_jiffies))return -ETIME ;
Greg Kroah-Hartman
maintainerPATCH 107/135 drm/amdkfd: Change the control stack MTYPE from UC to NC on GFX9
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yong Zhao <[email protected]>
[ Upstream commit 15426dbb65c5b37680d27e84d58a1ed3b8532518 ]
CWSR fails on Raven if the control stack is MTYPE_UC, which is used for regular GART mappings. As a workaround we map it using MTYPE_NC.
The MEC firmware expects the control stack at one page offset from the start of the MQD so it is part of the MQD allocation on GFXv9. AMDGPU added a memory allocation flag just for this purpose.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 6 +++++- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 ++- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 2 +- drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +- 5 files changed, 10 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c +5 -1
@@ -245,7 +245,7 @@ int amdgpu_amdkfd_resume(struct amdgpu_dint alloc_gtt_mem (struct kgd_dev *kgd,size_t size,void **mem_obj,uint64_t *gpu_addr, -void **cpu_ptr) +void **cpu_ptr,bool mqd_gfx9) {struct amdgpu_device *adev = (struct amdgpu_device *)kgd;struct amdgpu_bo *bo =NULL ;
@@ -261,6 +261,10 @@ int alloc_gtt_mem(struct kgd_dev *kgd, s bp.flags =AMDGPU_GEM_CREATE_CPU_GTT_USWC ; bp.type = ttm_bo_type_kernel; bp.resv =NULL ; + +if (mqd_gfx9) + bp.flags |=AMDGPU_GEM_CREATE_MQD_GFX9 ; + r =amdgpu_bo_create (adev, &bp, &bo);if (r) { dev_err(adev->dev,
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h +1 -1
@@ -129,7 +129,7 @@ bool amdgpu_amdkfd_is_kfd_vmid(struct am/* Shared API */ int alloc_gtt_mem (struct kgd_dev *kgd,size_t size,void **mem_obj,uint64_t *gpu_addr, -void **cpu_ptr); +void **cpu_ptr,bool mqd_gfx9);void free_gtt_mem (struct kgd_dev *kgd,void *mem_obj);void get_local_mem_info (struct kgd_dev *kgd,struct kfd_local_mem_info *mem_info);
drivers/gpu/drm/amd/amdkfd/kfd_device.c +2 -1
@@ -423,7 +423,8 @@ bool kgd2kfd_device_init(struct kfd_devif (kfd->kfd2kgd->init_gtt_mem_allocation ( kfd->kgd, size, &kfd->gtt_mem, - &kfd->gtt_start_gpu_addr, &kfd->gtt_start_cpu_ptr)){ + &kfd->gtt_start_gpu_addr, &kfd->gtt_start_cpu_ptr, + false)) {dev_err (kfd_device,"Could not allocate %d bytes\n" , size); goto out; }
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c +1 -1
@@ -63,7 +63,7 @@ static int init_mqd(struct mqd_manager *ALIGN (sizeof (struct v9_mqd ),PAGE_SIZE ), &((*mqd_mem_obj)->gtt_mem), &((*mqd_mem_obj)->gpu_addr), - (void *)&((*mqd_mem_obj)->cpu_ptr)); + (void *)&((*mqd_mem_obj)->cpu_ptr), true); }else retval =kfd_gtt_sa_allocate (mm->dev,sizeof (struct v9_mqd ), mqd_mem_obj);
drivers/gpu/drm/amd/include/kgd_kfd_interface.h +1 -1
@@ -266,7 +266,7 @@ struct tile_config {struct kfd2kgd_calls {int (*init_gtt_mem_allocation)(struct kgd_dev *kgd,size_t size,void **mem_obj,uint64_t *gpu_addr, -void **cpu_ptr); +void **cpu_ptr,bool mqd_gfx9);void (*free_gtt_mem)(struct kgd_dev *kgd,void *mem_obj);
Greg Kroah-Hartman
maintainerPATCH 108/135 drm/amdkfd: Fix ATS capablity was not reported correctly on some APUs
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yong Zhao <[email protected]>
[ Upstream commit 44d8cc6f1a905e4bb1d4221a898abb0d7e9d100a ]
Because CRAT_CU_FLAGS_IOMMU_PRESENT was not set in some BIOS crat, we need to workaround this.
For future compatibility, we also overwrite the bit in capability according to the value of needs_iommu_device.
--- drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 13 ++++++++++++- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 21 ++++++++++++++++----- 3 files changed, 29 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c +12 -1
@@ -62,9 +62,20 @@ int kfd_iommu_device_init(struct kfd_devstruct amd_iommu_device_info iommu_info;unsigned int pasid_limit;int err; +struct kfd_topology_device *top_dev; -if (!kfd->device_info->needs_iommu_device) + top_dev =kfd_topology_device_by_id (kfd->id); + +/* +* Overwrite ATS capability according to needs_iommu_device to fix +* potential missing corresponding bit in CRAT of BIOS. +*/ +if (!kfd->device_info->needs_iommu_device) { + top_dev->node_props.capability &= ~HSA_CAP_ATS_PRESENT ;return 0 ; + } + + top_dev->node_props.capability |=HSA_CAP_ATS_PRESENT ; iommu_info.flags =0 ; err =amd_iommu_device_info (kfd->pdev, &iommu_info);
drivers/gpu/drm/amd/amdkfd/kfd_priv.h +1 -0
@@ -796,6 +796,7 @@ int kfd_topology_add_device(struct kfd_dint kfd_topology_remove_device (struct kfd_dev *gpu);struct kfd_topology_device *kfd_topology_device_by_proximity_domain (uint32_t proximity_domain); +struct kfd_topology_device *kfd_topology_device_by_id (uint32_t gpu_id);struct kfd_dev *kfd_device_by_id (uint32_t gpu_id);struct kfd_dev *kfd_device_by_pci_dev (const struct pci_dev *pdev);int kfd_topology_enum_kfd_devices (uint8_t idx,struct kfd_dev **kdev);
drivers/gpu/drm/amd/amdkfd/kfd_topology.c +16 -5
@@ -63,22 +63,33 @@ struct kfd_topology_device *kfd_topologyreturn device; } -struct kfd_dev *kfd_device_by_id (uint32_t gpu_id) +struct kfd_topology_device *kfd_topology_device_by_id (uint32_t gpu_id) { -struct kfd_topology_device *top_dev; -struct kfd_dev *device =NULL ; +struct kfd_topology_device *top_dev =NULL ; +struct kfd_topology_device *ret =NULL ;down_read (&topology_lock);list_for_each_entry (top_dev, &topology_device_list, list)if (top_dev->gpu_id == gpu_id) { - device = top_dev->gpu; + ret = top_dev;break ; }up_read (&topology_lock); -return device; +return ret; +} + +struct kfd_dev *kfd_device_by_id (uint32_t gpu_id) +{ +struct kfd_topology_device *top_dev; + + top_dev =kfd_topology_device_by_id (gpu_id); +if (!top_dev) +return NULL ; + +return top_dev->gpu; }struct kfd_dev *kfd_device_by_pci_dev (const struct pci_dev *pdev)
Greg Kroah-Hartman
maintainerPATCH 82/135 Bluetooth: SMP: Fix trying to use non-existent local OOB data
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hedberg <[email protected]>
[ Upstream commit 94f14e4728125f979629b2b020d31cd718191626 ]
A remote device may claim that it has received our OOB data, even though we never geneated it. Add a new flag to track whether we actually have OOB data, and ignore the remote peer's flag if haven't generated OOB data.
--- net/bluetooth/smp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
net/bluetooth/smp.c +6 -2
@@ -83,6 +83,7 @@ enum {struct smp_dev {/* Secure Connections OOB data */ +bool local_oob;u8 local_pk[64 ];u8 local_rand[16 ];bool debug_key;
@@ -599,6 +600,8 @@ int smp_generate_oob(struct hci_dev *hdememcpy (rand, smp->local_rand,16 ); + smp->local_oob = true; +return 0 ; }
@@ -1785,7 +1788,7 @@ static u8 smp_cmd_pairing_req(struct l2c* successfully received our local OOB data - therefore set the * flag to indicate that local OOB is in use. */ -if (req->oob_flag ==SMP_OOB_PRESENT ) +if (req->oob_flag ==SMP_OOB_PRESENT &&SMP_DEV (hdev)->local_oob)set_bit (SMP_FLAG_LOCAL_OOB , &smp->flags);/* SMP over BR/EDR requires special treatment */
@@ -1967,7 +1970,7 @@ static u8 smp_cmd_pairing_rsp(struct l2c* successfully received our local OOB data - therefore set the * flag to indicate that local OOB is in use. */ -if (rsp->oob_flag ==SMP_OOB_PRESENT ) +if (rsp->oob_flag ==SMP_OOB_PRESENT &&SMP_DEV (hdev)->local_oob)set_bit (SMP_FLAG_LOCAL_OOB , &smp->flags); smp->prsp[0 ] =SMP_CMD_PAIRING_RSP ;
@@ -3230,6 +3233,7 @@ static struct l2cap_chan *smp_add_cid(streturn ERR_CAST (tfm_ecdh); } + smp->local_oob = false; smp->tfm_aes = tfm_aes; smp->tfm_cmac = tfm_cmac; smp->tfm_ecdh = tfm_ecdh;
Greg Kroah-Hartman
maintainerPATCH 109/135 mm: slowly shrink slabs with a relatively small number of objects
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Gushchin <[email protected]>
[ Upstream commit 172b06c32b949759fe6313abec514bc4f15014f4 ]
9092c71bb724 ("mm: use sc->priority for slab shrink targets") changed the way that the target slab pressure is calculated and made it priority-based:
delta = freeable >> priority;
delta *= 4;
do_div(delta, shrinker->seeks);The problem is that on a default priority (which is 12) no pressure is applied at all, if the number of potentially reclaimable objects is less than 4096 (1<<12).
This causes the last objects on slab caches of no longer used cgroups to (almost) never get reclaimed. It's obviously a waste of memory.
It can be especially painful, if these stale objects are holding a reference to a dying cgroup. Slab LRU lists are reparented on memcg offlining, but corresponding objects are still holding a reference to the dying cgroup. If we don't scan these objects, the dying cgroup can't go away. Most likely, the parent cgroup hasn't any directly charged objects, only remaining objects from dying children cgroups. So it can easily hold a reference to hundreds of dying cgroups.
If there are no big spikes in memory pressure, and new memory cgroups are created and destroyed periodically, this causes the number of dying cgroups grow steadily, causing a slow-ish and hard-to-detect memory "leak". It's not a real leak, as the memory can be eventually reclaimed, but it could not happen in a real life at all. I've seen hosts with a steadily climbing number of dying cgroups, which doesn't show any signs of a decline in months, despite the host is loaded with a production workload.
It is an obvious waste of memory, and to prevent it, let's apply a minimal pressure even on small shrinker lists. E.g. if there are freeable objects, let's scan at least min(freeable, scan_batch) objects.
This fix significantly improves a chance of a dying cgroup to be reclaimed, and together with some previous patches stops the steady growth of the dying cgroups number on some of our hosts.
--- mm/vmscan.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
mm/vmscan.c +11 -0
@@ -386,6 +386,17 @@ static unsigned long do_shrink_slab(stru delta = freeable >> priority; delta *=4 ;do_div (delta, shrinker->seeks); + +/* +* Make sure we apply some minimal pressure on default priority +* even on small cgroups. Stale objects are not only consuming memory +* by themselves, but can also hold a reference to a dying cgroup, +* preventing it from being reclaimed. A dying cgroup with all +* corresponding structures like per-cpu stats and kmem caches +* can be really big, so it may lead to a significant waste of memory. +*/ + delta = max_t(unsigned long long, delta, min(freeable, batch_size)); + total_scan += delta;if (total_scan <0 ) { pr_err("shrink_slab: %pF negative objects to delete nr=%ld\n",
Greg Kroah-Hartman
maintainerPATCH 110/135 mm/vmstat.c: fix outdated vmstat_text
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 28e2c4bb99aa40f9d5f07ac130cbc4da0ea93079 upstream.
7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely") removed the VMACACHE_FULL_FLUSHES statistics, but didn't remove the corresponding entry in vmstat_text. This causes an out-of-bounds access in vmstat_show().
Luckily this only affects kernels with CONFIG_DEBUG_VM_VMACACHE=y, which is probably very rare.
--- mm/vmstat.c | 1 - 1 file changed, 1 deletion(-)
mm/vmstat.c +0 -1
@@ -1286,7 +1286,6 @@ const char * const vmstat_text[] = {#ifdef CONFIG_DEBUG_VM_VMACACHE "vmacache_find_calls" ,"vmacache_find_hits" , -"vmacache_full_flushes" , #endif #ifdef CONFIG_SWAP "swap_ra",
Greg Kroah-Hartman
maintainerPATCH 111/135 afs: Fix afs_server struct leak
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit f014ffb025c159fd51d19af8af0022a991aaa4f8 upstream.
Fix a leak of afs_server structs. The routine that installs them in the various lookup lists and trees gets a ref on leaving the function, whether it added the server or a server already exists. It shouldn't increment the refcount if it added the server.
The effect of this that "rmmod kafs" will hang waiting for the leaked server to become unused.
--- fs/afs/server.c | 2 ++ 1 file changed, 2 insertions(+)
fs/afs/server.c +2 -0
@@ -199,9 +199,11 @@ static struct afs_server *afs_install_sewrite_sequnlock (&net->fs_addr_lock); ret =0 ; + goto out; exists:afs_get_server (server); +out:write_sequnlock (&net->fs_lock);return server; }
Greg Kroah-Hartman
maintainerPATCH 112/135 afs: Fix clearance of reply
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit f0a7d1883d9f78ae7bf15fc258bf9a2b20f35b76 upstream.
The recent patch to fix the afs_server struct leak didn't actually fix the bug, but rather fixed some of the symptoms. The problem is that an asynchronous call that holds a resource pointed to by call->reply[0] will find the pointer cleared in the call destructor, thereby preventing the resource from being cleaned up.
In the case of the server record leak, the afs_fs_get_capabilities() function in devel code sets up a call with reply[0] pointing at the server record that should be altered when the result is obtained, but this was being cleared before the destructor was called, so the put in the destructor does nothing and the record is leaked.
Commit f014ffb025c1 removed the additional ref obtained by afs_install_server(), but the removal of this ref is actually used by the garbage collector to mark a server record as being defunct after the record has expired through lack of use.
The offending clearance of call->reply[0] upon completion in afs_process_async_call() has been there from the origin of the code, but none of the asynchronous calls actually use that pointer currently, so it should be safe to remove (note that synchronous calls don't involve this function).
Fix this by the following means:
(1) Revert commit f014ffb025c1.
(2) Remove the clearance of reply[0] from afs_process_async_call().
Without this, afs_manage_servers() will suffer an assertion failure if it sees a server record that didn't get used because the usage count is not 1.
--- fs/afs/rxrpc.c | 2 -- fs/afs/server.c | 2 -- 2 files changed, 4 deletions(-)
fs/afs/rxrpc.c +0 -2
@@ -690,8 +690,6 @@ static void afs_process_async_call(struc }if (call->state ==AFS_CALL_COMPLETE ) { - call->reply[0 ] =NULL ; -/* We have two refs to release - one from the alloc and one * queued with the work item - and we can't just deallocate the * call because the work item may be queued again.
fs/afs/server.c +0 -2
@@ -199,11 +199,9 @@ static struct afs_server *afs_install_sewrite_sequnlock (&net->fs_addr_lock); ret =0 ; - goto out; exists:afs_get_server (server); -out:write_sequnlock (&net->fs_lock);return server; }
Greg Kroah-Hartman
maintainerPATCH 116/135 vsprintf: Fix off-by-one bug in bstr_printf() processing dereferenced pointers
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (VMware) <[email protected]>
commit 62165600ae73ebd76e2d9b992b36360408d570d8 upstream.
The functions vbin_printf() and bstr_printf() are used by trace_printk() to try to keep the overhead down during printing. trace_printk() uses vbin_printf() at the time of execution, as it only scans the fmt string to record the printf values into the buffer, and then uses vbin_printf() to do the conversions to print the string based on the format and the saved values in the buffer.
This is an issue for dereferenced pointers, as before commit 841a915d20c7b, the processing of the pointer could happen some time after the pointer value was recorded (reading the trace buffer). This means the processing of the value at a later time could show different results, or even crash the system, if the pointer no longer existed.
Commit 841a915d20c7b addressed this by processing dereferenced pointers at the time of execution and save the result in the ring buffer as a string. The bstr_printf() would then treat these pointers as normal strings, and print the value. But there was an off-by-one bug here, where after processing the argument, it move the pointer only "strlen(arg)" which made the arg pointer not point to the next argument in the ring buffer, but instead point to the nul character of the last argument. This causes any values after a dereferenced pointer to be corrupted.
--- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/vsprintf.c +1 -1
@@ -2769,7 +2769,7 @@ int bstr_printf(char *buf, size_t size, copy = end - str;memcpy (str, args, copy); str += len; - args += len; + args += len +1 ; } }if (process)
Greg Kroah-Hartman
maintainerPATCH 117/135 percpu: stop leaking bitmap metadata blocks
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Rapoport <[email protected]>
commit 6685b357363bfe295e3ae73665014db4aed62c58 upstream.
The commit ca460b3c9627 ("percpu: introduce bitmap metadata blocks") introduced bitmap metadata blocks. These metadata blocks are allocated whenever a new chunk is created, but they are never freed. Fix it.
--- mm/percpu.c | 1 + 1 file changed, 1 insertion(+)
mm/percpu.c +1 -0
@@ -1204,6 +1204,7 @@ static void pcpu_free_chunk(struct pcpu_ {if (!chunk)return ; +pcpu_mem_free (chunk->md_blocks);pcpu_mem_free (chunk->bound_map);pcpu_mem_free (chunk->alloc_map);pcpu_mem_free (chunk);
Greg Kroah-Hartman
maintainerPATCH 118/135 perf script python: Fix export-to-postgresql.py occasional failure
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 25e11700b54c7b6b5ebfc4361981dae12299557b upstream.
Occasional export failures were found to be caused by truncating 64-bit pointers to 32-bits. Fix by explicitly setting types for all ctype arguments and results.
--- tools/perf/scripts/python/export-to-postgresql.py | 9 +++++++++ 1 file changed, 9 insertions(+)
tools/perf/scripts/python/export-to-postgresql.py +9 -0
@@ -204,14 +204,23 @@ from ctypes import * libpq = CDLL("libpq.so.5") PQconnectdb = libpq.PQconnectdb PQconnectdb.restype = c_void_p +PQconnectdb.argtypes = [ c_char_p ] PQfinish = libpq.PQfinish +PQfinish.argtypes = [ c_void_p ] PQstatus = libpq.PQstatus +PQstatus.restype = c_int +PQstatus.argtypes = [ c_void_p ] PQexec = libpq.PQexec PQexec.restype = c_void_p +PQexec.argtypes = [ c_void_p, c_char_p ] PQresultStatus = libpq.PQresultStatus +PQresultStatus.restype = c_int +PQresultStatus.argtypes = [ c_void_p ] PQputCopyData = libpq.PQputCopyData +PQputCopyData.restype = c_int PQputCopyData.argtypes = [ c_void_p, c_void_p, c_int ] PQputCopyEnd = libpq.PQputCopyEnd +PQputCopyEnd.restype = c_int PQputCopyEnd.argtypes = [ c_void_p, c_void_p ] sys.path.append(os.environ['PERF_EXEC_PATH'] + \
Greg Kroah-Hartman
maintainerPATCH 83/135 Bluetooth: Use correct tfm to generate OOB data
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matias Karhumaa <[email protected]>
[ Upstream commit 4ba5175f2c10affd412fa41855cecda02b66cd71 ]
In case local OOB data was generated and other device initiated pairing claiming that it has got OOB data, following crash occurred:
[ 222.847853] general protection fault: 0000 [#1] SMP PTI [ 222.848025] CPU: 1 PID: 42 Comm: kworker/u5:0 Tainted: G C 4.18.0-custom #4 [ 222.848158] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 222.848307] Workqueue: hci0 hci_rx_work [bluetooth] [ 222.848416] RIP: 0010:compute_ecdh_secret+0x5a/0x270 [bluetooth] [ 222.848540] Code: 0c af f5 48 8b 3d 46 de f0 f6 ba 40 00 00 00 be c0 00 60 00 e8 b7 7b c5 f5 48 85 c0 0f 84 ea 01 00 00 48 89 c3 e8 16 0c af f5 <49> 8b 47 38 be c0 00 60 00 8b 78 f8 48 83 c7 48 e8 51 84 c5 f5 48 [ 222.848914] RSP: 0018:ffffb1664087fbc0 EFLAGS: 00010293 [ 222.849021] RAX: ffff8a5750d7dc00 RBX: ffff8a5671096780 RCX: ffffffffc08bc32a [ 222.849111] RDX: 0000000000000000 RSI: 00000000006000c0 RDI: ffff8a5752003800 [ 222.849192] RBP: ffffb1664087fc60 R08: ffff8a57525280a0 R09: ffff8a5752003800 [ 222.849269] R10: ffffb1664087fc70 R11: 0000000000000093 R12: ffff8a5674396e00 [ 222.849350] R13: ffff8a574c2e79aa R14: ffff8a574c2e796a R15: 020e0e100d010101 [ 222.849429] FS: 0000000000000000(0000) GS:ffff8a5752500000(0000) knlGS:0000000000000000 [ 222.849518] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 222.849586] CR2: 000055856016a038 CR3: 0000000110d2c005 CR4: 00000000000606e0 [ 222.849671] Call Trace: [ 222.849745] ? sc_send_public_key+0x110/0x2a0 [bluetooth] [ 222.849825] ? sc_send_public_key+0x115/0x2a0 [bluetooth] [ 222.849925] smp_recv_cb+0x959/0x2490 [bluetooth] [ 222.850023] ? _cond_resched+0x19/0x40 [ 222.850105] ? mutex_lock+0x12/0x40 [ 222.850202] l2cap_recv_frame+0x109d/0x3420 [bluetooth] [ 222.850315] ? l2cap_recv_frame+0x109d/0x3420 [bluetooth] [ 222.850426] ? __switch_to_asm+0x34/0x70 [ 222.850515] ? __switch_to_asm+0x40/0x70 [ 222.850625] ? __switch_to_asm+0x34/0x70 [ 222.850724] ? __switch_to_asm+0x40/0x70 [ 222.850786] ? __switch_to_asm+0x34/0x70 [ 222.850846] ? __switch_to_asm+0x40/0x70 [ 222.852581] ? __switch_to_asm+0x34/0x70 [ 222.854976] ? __switch_to_asm+0x40/0x70 [ 222.857475] ? __switch_to_asm+0x40/0x70 [ 222.859775] ? __switch_to_asm+0x34/0x70 [ 222.861218] ? __switch_to_asm+0x40/0x70 [ 222.862327] ? __switch_to_asm+0x34/0x70 [ 222.863758] l2cap_recv_acldata+0x266/0x3c0 [bluetooth] [ 222.865122] hci_rx_work+0x1c9/0x430 [bluetooth] [ 222.867144] process_one_work+0x210/0x4c0 [ 222.868248] worker_thread+0x41/0x4d0 [ 222.869420] kthread+0x141/0x160 [ 222.870694] ? process_one_work+0x4c0/0x4c0 [ 222.871668] ? kthread_create_worker_on_cpu+0x90/0x90 [ 222.872896] ret_from_fork+0x35/0x40 [ 222.874132] Modules linked in: algif_hash algif_skcipher af_alg rfcomm bnep btusb btrtl btbcm btintel snd_intel8x0 cmac intel_rapl_perf vboxvideo(C) snd_ac97_codec bluetooth ac97_bus joydev ttm snd_pcm ecdh_generic drm_kms_helper snd_timer snd input_leds drm serio_raw fb_sys_fops soundcore syscopyarea sysfillrect sysimgblt mac_hid sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ahci psmouse libahci i2c_piix4 video e1000 pata_acpi [ 222.883153] fbcon_switch: detected unhandled fb_set_par error, error code -16 [ 222.886774] fbcon_switch: detected unhandled fb_set_par error, error code -16 [ 222.890503] ---[ end trace 6504aa7a777b5316 ]--- [ 222.890541] RIP: 0010:compute_ecdh_secret+0x5a/0x270 [bluetooth] [ 222.890551] Code: 0c af f5 48 8b 3d 46 de f0 f6 ba 40 00 00 00 be c0 00 60 00 e8 b7 7b c5 f5 48 85 c0 0f 84 ea 01 00 00 48 89 c3 e8 16 0c af f5 <49> 8b 47 38 be c0 00 60 00 8b 78 f8 48 83 c7 48 e8 51 84 c5 f5 48 [ 222.890555] RSP: 0018:ffffb1664087fbc0 EFLAGS: 00010293 [ 222.890561] RAX: ffff8a5750d7dc00 RBX: ffff8a5671096780 RCX: ffffffffc08bc32a [ 222.890565] RDX: 0000000000000000 RSI: 00000000006000c0 RDI: ffff8a5752003800 [ 222.890571] RBP: ffffb1664087fc60 R08: ffff8a57525280a0 R09: ffff8a5752003800 [ 222.890576] R10: ffffb1664087fc70 R11: 0000000000000093 R12: ffff8a5674396e00 [ 222.890581] R13: ffff8a574c2e79aa R14: ffff8a574c2e796a R15: 020e0e100d010101 [ 222.890586] FS: 0000000000000000(0000) GS:ffff8a5752500000(0000) knlGS:0000000000000000 [ 222.890591] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 222.890594] CR2: 000055856016a038 CR3: 0000000110d2c005 CR4: 00000000000606e0
This commit fixes a bug where invalid pointer to crypto tfm was used for SMP SC ECDH calculation when OOB was in use. Solution is to use same crypto tfm than when generating OOB material on generate_oob() function.
This bug was introduced in commit c0153b0b901a ("Bluetooth: let the crypto subsystem generate the ecc privkey"). Bug was found by fuzzing kernel SMP implementation using Synopsys Defensics.
--- net/bluetooth/smp.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
net/bluetooth/smp.c +7 -1
@@ -2700,7 +2700,13 @@ static int smp_cmd_public_key(struct l2c* key was set/generated. */ if (test_bit (SMP_FLAG_LOCAL_OOB , &smp->flags)) { -struct smp_dev *smp_dev = chan->data; +struct l2cap_chan *hchan = hdev->smp_data; +struct smp_dev *smp_dev; + +if (!hchan || !hchan->data) +return SMP_UNSPECIFIED ; + + smp_dev = hchan->data; tfm_ecdh = smp_dev->tfm_ecdh; }else {
Greg Kroah-Hartman
maintainerPATCH 84/135 Bluetooth: hci_ldisc: Free rw_semaphore on close
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hermes Zhang <[email protected]>
[ Upstream commit e6a57d22f787e73635ce0d29eef0abb77928b3e9 ]
The percpu_rw_semaphore is not currently freed, and this leads to a crash when the stale rcu callback is invoked. DEBUG_OBJECTS detects this.
ODEBUG: free active (active state 1) object type: rcu_head hint: (null)
------------[ cut here ]------------ WARNING: CPU: 1 PID: 2024 at debug_print_object+0xac/0xc8 PC is at debug_print_object+0xac/0xc8 LR is at debug_print_object+0xac/0xc8 Call trace: [<ffffff80082e2c2c>] debug_print_object+0xac/0xc8 [<ffffff80082e40b0>] debug_check_no_obj_freed+0x1e8/0x228 [<ffffff8008191254>] kfree+0x1cc/0x250 [<ffffff80083cc03c>] hci_uart_tty_close+0x54/0x108 [<ffffff800832e118>] tty_ldisc_close.isra.1+0x40/0x58 [<ffffff800832e14c>] tty_ldisc_kill+0x1c/0x40 [<ffffff800832e3dc>] tty_ldisc_release+0x94/0x170 [<ffffff8008325554>] tty_release_struct+0x1c/0x58 [<ffffff8008326400>] tty_release+0x3b0/0x490 [<ffffff80081a3fe8>] __fput+0x88/0x1d0 [<ffffff80081a418c>] ____fput+0xc/0x18 [<ffffff80080c0624>] task_work_run+0x9c/0xc0 [<ffffff80080a9e24>] do_exit+0x24c/0x8a0 [<ffffff80080aa4e0>] do_group_exit+0x38/0xa0 [<ffffff80080aa558>] __wake_up_parent+0x0/0x28 [<ffffff8008082c00>] el0_svc_naked+0x34/0x38 ---[ end trace bfe08cbd89098cdf ]---
--- drivers/bluetooth/hci_ldisc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/hci_ldisc.c +2 -0
@@ -543,6 +543,8 @@ static void hci_uart_tty_close(struct tt }clear_bit (HCI_UART_PROTO_SET , &hu->flags); +percpu_free_rwsem (&hu->proto_lock); +kfree (hu); }
Greg Kroah-Hartman
maintainerPATCH 85/135 mfd: omap-usb-host: Fix dts probe of children
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <[email protected]>
[ Upstream commit 10492ee8ed9188d6d420e1f79b2b9bdbc0624e65 ]
It currently only works if the parent bus uses "simple-bus". We currently try to probe children with non-existing compatible values. And we're missing .probe.
I noticed this while testing devices configured to probe using ti-sysc interconnect target module driver. For that we also may want to rebind the driver, so let's remove __init and __exit.
--- drivers/mfd/omap-usb-host.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/mfd/omap-usb-host.c +6 -5
@@ -528,8 +528,8 @@ static int usbhs_omap_get_dt_pdata(struc }static const struct of_device_id usbhs_child_match_table[] = { - { .compatible ="ti,omap-ehci" , }, - { .compatible ="ti,omap-ohci" , }, + { .compatible ="ti,ehci-omap" , }, + { .compatible ="ti,ohci-omap3" , }, { } };
@@ -855,6 +855,7 @@ static struct platform_driver usbhs_omap .pm = &usbhsomap_dev_pm_ops, .of_match_table = usbhs_omap_dt_ids, }, + .probe = usbhs_omap_probe, .remove = usbhs_omap_remove, };
@@ -864,9 +865,9 @@ MODULE_ALIAS("platform:" USBHS_DRIVER_NAMODULE_LICENSE ("GPL v2" );MODULE_DESCRIPTION ("usb host common core driver for omap EHCI and OHCI" ); -static int __init omap_usbhs_drvinit (void ) +static int omap_usbhs_drvinit (void ) { -return platform_driver_probe (&usbhs_omap_driver, usbhs_omap_probe); +return platform_driver_register (&usbhs_omap_driver); }/*
@@ -878,7 +879,7 @@ static int __init omap_usbhs_drvinit(voi*/ fs_initcall_sync (omap_usbhs_drvinit); -static void __exit omap_usbhs_drvexit(void) +static void omap_usbhs_drvexit (void ) {platform_driver_unregister (&usbhs_omap_driver); }
Greg Kroah-Hartman
maintainerPATCH 88/135 scsi: qla2xxx: Fix an endian bug in fcpcmd_is_corrupted()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit cbe3fd39d223f14b1c60c80fe9347a3dd08c2edb ]
We should first do the le16_to_cpu endian conversion and then apply the FCP_CMD_LENGTH_MASK mask.
--- drivers/scsi/qla2xxx/qla_target.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_target.h +2 -2
@@ -374,8 +374,8 @@ struct atio_from_isp {static inline int fcpcmd_is_corrupted (struct atio *atio) {if (atio->entry_type ==ATIO_TYPE7 && - (le16_to_cpu (atio->attr_n_length &FCP_CMD_LENGTH_MASK ) < -FCP_CMD_LENGTH_MIN )) + ((le16_to_cpu (atio->attr_n_length) &FCP_CMD_LENGTH_MASK ) < +FCP_CMD_LENGTH_MIN ))return 1 ;else return 0 ;
Greg Kroah-Hartman
maintainerPATCH 79/135 Add tests for memory.oom.group
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jay Kamat <[email protected]>
[ Upstream commit a987785dcd6c8ae2915460582aebd6481c81eb67 ]
Add tests for memory.oom.group for the following cases:
- Killing all processes in a leaf cgroup, but leaving the parent untouched
- Killing all processes in a parent and leaf cgroup
- Keeping processes marked by OOM_SCORE_ADJ_MIN alive when considered for being killed by the group oom killer.
--- tools/testing/selftests/cgroup/cgroup_util.c | 21 ++ tools/testing/selftests/cgroup/cgroup_util.h | 1 tools/testing/selftests/cgroup/test_memcontrol.c | 205 +++++++++++++++++++++++ 3 files changed, 227 insertions(+)
tools/testing/selftests/cgroup/cgroup_util.c +21 -0
@@ -340,3 +340,24 @@ int is_swap_enabled(void)return cnt >1 ; } + +int set_oom_adj_score (int pid,int score) +{ +char path[PATH_MAX ]; +int fd, len; + +sprintf (path,"/proc/%d/oom_score_adj" , pid); + + fd =open (path,O_WRONLY |O_APPEND ); +if (fd <0 ) +return fd; + + len =dprintf (fd,"%d" , score); +if (len <0 ) { +close (fd); +return len; + } + +close (fd); +return 0 ; +}
tools/testing/selftests/cgroup/cgroup_util.h +1 -0
@@ -39,3 +39,4 @@ extern int get_temp_fd(void);extern int alloc_pagecache (int fd,size_t size);extern int alloc_anon (const char *cgroup,void *arg);extern int is_swap_enabled (void ); +extern int set_oom_adj_score (int pid,int score);
tools/testing/selftests/cgroup/test_memcontrol.c +205 -0
229 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 129/135 pinctrl: mcp23s08: fix irq and irqchip setup order
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Felsch <[email protected]>
commit f259f896f2348f0302f6f88d4382378cf9d23a7e upstream.
Since 'commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' the irq request isn't the last devm_* allocation. Without a deeper look at the irq and testing this isn't a good solution. Since this driver relies on the devm mechanism, requesting a interrupt should be the last thing to avoid memory corruptions during unbinding.
'Commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' fixed the order for the interrupt-controller use case only. The mcp23s08_irq_setup() must be split into two to fix it for the interrupt-controller use case and to register the irq at last. So the irq will be freed first during unbind.
--- drivers/pinctrl/pinctrl-mcp23s08.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/pinctrl/pinctrl-mcp23s08.c +12 -1
@@ -636,6 +636,14 @@ static int mcp23s08_irq_setup(struct mcpreturn err; } +return 0 ; +} + +static int mcp23s08_irqchip_setup (struct mcp23s08 *mcp) +{ +struct gpio_chip *chip = &mcp->chip; +int err; + err = gpiochip_irqchip_add_nested(chip, &mcp23s08_irq_chip, 0,
@@ -912,7 +920,7 @@ static int mcp23s08_probe_one(struct mcp }if (mcp->irq && mcp->irq_controller) { - ret =mcp23s08_irq_setup (mcp); + ret =mcp23s08_irqchip_setup (mcp);if (ret) goto fail; }
@@ -944,6 +952,9 @@ static int mcp23s08_probe_one(struct mcp goto fail; } +if (mcp->irq) + ret =mcp23s08_irq_setup (mcp); + fail:if (ret <0 )dev_dbg (dev,"can't setup chip %d, --> %d\n" , addr, ret);
Greg Kroah-Hartman
maintainerPATCH 130/135 arm64: perf: Reject stand-alone CHAIN events for PMUv3
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit ca2b497253ad01c80061a1f3ee9eb91b5d54a849 upstream.
It doesn't make sense for a perf event to be configured as a CHAIN event in isolation, so extend the arm_pmu structure with a ->filter_match() function to allow the backend PMU implementation to reject CHAIN events early.
--- arch/arm64/kernel/perf_event.c | 7 +++++++ drivers/perf/arm_pmu.c | 8 +++++++- include/linux/perf/arm_pmu.h | 1 + 3 files changed, 15 insertions(+), 1 deletion(-)
arch/arm64/kernel/perf_event.c +7 -0
@@ -823,6 +823,12 @@ static int armv8pmu_set_event_filter(strreturn 0 ; } +static int armv8pmu_filter_match (struct perf_event *event) +{ +unsigned long evtype = event->hw.config_base &ARMV8_PMU_EVTYPE_EVENT ; +return evtype !=ARMV8_PMUV3_PERFCTR_CHAIN ; +} +static void armv8pmu_reset (void *info) {struct arm_pmu *cpu_pmu = (struct arm_pmu *)info;
@@ -968,6 +974,7 @@ static int armv8_pmu_init(struct arm_pmu cpu_pmu->reset = armv8pmu_reset, cpu_pmu->max_period = (1LLU <<32 ) -1 , cpu_pmu->set_event_filter = armv8pmu_set_event_filter; + cpu_pmu->filter_match = armv8pmu_filter_match;return 0 ; }
drivers/perf/arm_pmu.c +7 -1
@@ -474,7 +474,13 @@ static int armpmu_filter_match(struct pe {struct arm_pmu *armpmu =to_arm_pmu (event->pmu);unsigned int cpu =smp_processor_id (); -return cpumask_test_cpu (cpu, &armpmu->supported_cpus); +int ret; + + ret =cpumask_test_cpu (cpu, &armpmu->supported_cpus); +if (ret && armpmu->filter_match) +return armpmu->filter_match (event); + +return ret; } static ssize_t armpmu_cpumask_show(struct device *dev,
include/linux/perf/arm_pmu.h +1 -0
@@ -93,6 +93,7 @@ struct arm_pmu {void (*stop)(struct arm_pmu *);void (*reset)(void *);int (*map_event)(struct perf_event *event); +int (*filter_match)(struct perf_event *event);int num_events;u64 max_period;bool secure_access;/* 32-bit ARM only */
Greg Kroah-Hartman
maintainerPATCH 131/135 mm/mmap.c: dont clobber partially overlapping VMA with MAP_FIXED_NOREPLACE
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 7aa867dd89526e9cfd9714d8b9b587c016eaea34 upstream.
Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an application causes that application to randomly crash. The existing check for handling MAP_FIXED_NOREPLACE looks up the first VMA that either overlaps or follows the requested region, and then bails out if that VMA overlaps *the start* of the requested region. It does not bail out if the VMA only overlaps another part of the requested region.
Fix it by checking that the found VMA only starts at or after the end of the requested region, in which case there is no overlap.
Test case:
user@debian:~$ cat mmap_fixed_simple.c #include <sys/mman.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h>
#ifndef MAP_FIXED_NOREPLACE
#define MAP_FIXED_NOREPLACE 0x100000
#endif
int main(void) {
char *p;
errno = 0;
p = mmap((void*)0x10001000, 0x4000, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
printf("p1=%p err=%m\n", p);
errno = 0;
p = mmap((void*)0x10000000, 0x2000, PROT_READ,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
printf("p2=%p err=%m\n", p);
char cmd[100]; sprintf(cmd, "cat /proc/%d/maps", getpid()); system(cmd);
return 0;
}
user@debian:~$ gcc -o mmap_fixed_simple mmap_fixed_simple.c user@debian:~$ ./mmap_fixed_simple p1=0x10001000 err=Success p2=0x10000000 err=Success 10000000-10002000 r--p 00000000 00:00 0 10002000-10005000 ---p 00000000 00:00 0 564a9a06f000-564a9a070000 r-xp 00000000 fe:01 264004 /home/user/mmap_fixed_simple 564a9a26f000-564a9a270000 r--p 00000000 fe:01 264004 /home/user/mmap_fixed_simple 564a9a270000-564a9a271000 rw-p 00001000 fe:01 264004 /home/user/mmap_fixed_simple 564a9a54a000-564a9a56b000 rw-p 00000000 00:00 0 [heap] 7f8eba447000-7f8eba5dc000 r-xp 00000000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba5dc000-7f8eba7dc000 ---p 00195000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba7dc000-7f8eba7e0000 r--p 00195000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba7e0000-7f8eba7e2000 rw-p 00199000 fe:01 405885 /lib/x86_64-linux-gnu/libc-2.24.so 7f8eba7e2000-7f8eba7e6000 rw-p 00000000 00:00 0 7f8eba7e6000-7f8eba809000 r-xp 00000000 fe:01 405876 /lib/x86_64-linux-gnu/ld-2.24.so 7f8eba9e9000-7f8eba9eb000 rw-p 00000000 00:00 0 7f8ebaa06000-7f8ebaa09000 rw-p 00000000 00:00 0 7f8ebaa09000-7f8ebaa0a000 r--p 00023000 fe:01 405876 /lib/x86_64-linux-gnu/ld-2.24.so 7f8ebaa0a000-7f8ebaa0b000 rw-p 00024000 fe:01 405876 /lib/x86_64-linux-gnu/ld-2.24.so 7f8ebaa0b000-7f8ebaa0c000 rw-p 00000000 00:00 0 7ffcc99fa000-7ffcc9a1b000 rw-p 00000000 00:00 0 [stack] 7ffcc9b44000-7ffcc9b47000 r--p 00000000 00:00 0 [vvar] 7ffcc9b47000-7ffcc9b49000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] user@debian:~$ uname -a Linux debian 4.19.0-rc6+ #181 SMP Wed Oct 3 23:43:42 CEST 2018 x86_64 GNU/Linux user@debian:~$
As you can see, the first page of the mapping at 0x10001000 was clobbered.
--- mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/mmap.c +1 -1
@@ -1410,7 +1410,7 @@ unsigned long do_mmap(struct file *file,if (flags &MAP_FIXED_NOREPLACE ) {struct vm_area_struct *vma =find_vma (mm, addr); -if (vma && vma->vm_start <= addr) +if (vma && vma->vm_start < addr + len)return -EEXIST ; }
Greg Kroah-Hartman
maintainerPATCH 132/135 mm/thp: fix call to mmu_notifier in set_pmd_migration_entry() v2
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jérôme Glisse <[email protected]>
commit bfba8e5cf28f413aa05571af493871d74438979f upstream.
Inside set_pmd_migration_entry() we are holding page table locks and thus we can not sleep so we can not call invalidate_range_start/end()
So remove call to mmu_notifier_invalidate_range_start/end() because they are call inside the function calling set_pmd_migration_entry() (see try_to_unmap_one()).
--- mm/huge_memory.c | 6 ------ 1 file changed, 6 deletions(-)
mm/huge_memory.c +0 -6
@@ -2883,9 +2883,6 @@ void set_pmd_migration_entry(struct pageif (!(pvmw->pmd && !pvmw->pte))return ; -mmu_notifier_invalidate_range_start (mm, address, - address +HPAGE_PMD_SIZE ); -flush_cache_range (vma, address, address +HPAGE_PMD_SIZE ); pmdval = *pvmw->pmd;pmdp_invalidate (vma, address, pvmw->pmd);
@@ -2898,9 +2895,6 @@ void set_pmd_migration_entry(struct pageset_pmd_at (mm, address, pvmw->pmd, pmdswp);page_remove_rmap (page, true);put_page (page); - -mmu_notifier_invalidate_range_end (mm, address, - address +HPAGE_PMD_SIZE ); }void remove_migration_pmd (struct page_vma_mapped_walk *pvmw,struct page *new)
Greg Kroah-Hartman
maintainerPATCH 133/135 filesystem-dax: Fix dax_layout_busy_page() livelock
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit d7782145e1ad537df4ce74e58c50f1f732a1462d upstream.
In the presence of multi-order entries the typical pagevec_lookup_entries() pattern may loop forever:
while (index < end && pagevec_lookup_entries(&pvec, mapping, index,
min(end - index, (pgoff_t)PAGEVEC_SIZE),
indices)) {
...
for (i = 0; i < pagevec_count(&pvec); i++) {
index = indices[i];
...
}
index++; /* BUG */
}The loop updates 'index' for each index found and then increments to the next possible page to continue the lookup. However, if the last entry in the pagevec is multi-order then the next possible page index is more than 1 page away. Fix this locally for the filesystem-dax case by checking for dax-multi-order entries. Going forward new users of multi-order entries need to be similarly careful, or we need a generic way to report the page increment in the radix iterator.
--- fs/dax.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
fs/dax.c +11 -2
@@ -558,6 +558,8 @@ struct page *dax_layout_busy_page(structwhile (index < end &&pagevec_lookup_entries (&pvec, mapping, index,min (end - index, (pgoff_t )PAGEVEC_SIZE ), indices)) { +pgoff_t nr_pages =1 ; +for (i =0 ; i <pagevec_count (&pvec); i++) {struct page *pvec_ent = pvec.pages[i];void *entry;
@@ -571,8 +573,15 @@ struct page *dax_layout_busy_page(structxa_lock_irq (&mapping->i_pages); entry =get_unlocked_mapping_entry (mapping, index,NULL ); -if (entry) +if (entry) { page =dax_busy_page (entry); +/* +* Account for multi-order entries at +* the end of the pagevec. +*/ +if (i +1 >=pagevec_count (&pvec)) + nr_pages =1UL <<dax_radix_order (entry); + }put_unlocked_mapping_entry (mapping, index, entry);xa_unlock_irq (&mapping->i_pages);if (page)
@@ -580,7 +589,7 @@ struct page *dax_layout_busy_page(struct }pagevec_remove_exceptionals (&pvec);pagevec_release (&pvec); - index++; + index += nr_pages;if (page)break ;
Greg Kroah-Hartman
maintainerPATCH 134/135 mm: Preserve _PAGE_DEVMAP across mprotect() calls
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 4628a64591e6cee181237060961e98c615c33966 upstream.
Currently _PAGE_DEVMAP bit is not preserved in mprotect(2) calls. As a result we will see warnings such as:
BUG: Bad page map in process JobWrk0013 pte:800001803875ea25 pmd:7624381067 addr:00007f0930720000 vm_flags:280000f9 anon_vma: (null) mapping:ffff97f2384056f0 index:0 file:457-000000fe00000030-00000009-000000ca-00000001_2001.fileblock fault:xfs_filemap_fault [xfs] mmap:xfs_file_mmap [xfs] readpage: (null) CPU: 3 PID: 15848 Comm: JobWrk0013 Tainted: G W 4.12.14-2.g7573215-default #1 SLE12-SP4 (unreleased) Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.01.00.0833.051120182255 05/11/2018 Call Trace: dump_stack+0x5a/0x75 print_bad_pte+0x217/0x2c0 ? enqueue_task_fair+0x76/0x9f0 _vm_normal_page+0xe5/0x100 zap_pte_range+0x148/0x740 unmap_page_range+0x39a/0x4b0 unmap_vmas+0x42/0x90 unmap_region+0x99/0xf0 ? vma_gap_callbacks_rotate+0x1a/0x20 do_munmap+0x255/0x3a0 vm_munmap+0x54/0x80 SyS_munmap+0x1d/0x30 do_syscall_64+0x74/0x150 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
...
when mprotect(2) gets used on DAX mappings. Also there is a wide variety of other failures that can result from the missing _PAGE_DEVMAP flag when the area gets used by get_user_pages() later.
Fix the problem by including _PAGE_DEVMAP in a set of flags that get preserved by mprotect(2).
--- arch/powerpc/include/asm/book3s/64/pgtable.h | 4 ++-- arch/x86/include/asm/pgtable_types.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/powerpc/include/asm/book3s/64/pgtable.h +2 -2
@@ -104,7 +104,7 @@*/ #define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \ _PAGE_ACCESSED | H_PAGE_THP_HUGE | _PAGE_PTE | \ - _PAGE_SOFT_DIRTY) + _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)/* * user access blocked by key */
@@ -122,7 +122,7 @@*/ #define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \ _PAGE_ACCESSED | _PAGE_SPECIAL | _PAGE_PTE | \ - _PAGE_SOFT_DIRTY) + _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)#define H_PTE_PKEY (H_PTE_PKEY_BIT0 | H_PTE_PKEY_BIT1 | H_PTE_PKEY_BIT2 | \ H_PTE_PKEY_BIT3 | H_PTE_PKEY_BIT4)
arch/x86/include/asm/pgtable_types.h +1 -1
@@ -123,7 +123,7 @@*/ #define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ - _PAGE_SOFT_DIRTY) + _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)#define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)/*
Greg Kroah-Hartman
maintainerPATCH 121/135 dm cache: destroy migration_cache if cache target registration failed
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shenghui Wang <[email protected]>
commit c7cd55504a5b0fc826a2cd9540845979d24ae542 upstream.
Commit 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created") inadvertently introduced this bug when it moved dm_register_target() after the call to KMEM_CACHE().
--- drivers/md/dm-cache-target.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/md/dm-cache-target.c +2 -3
@@ -3492,14 +3492,13 @@ static int __init dm_cache_init(void)int r; migration_cache =KMEM_CACHE (dm_cache_migration,0 ); -if (!migration_cache) { -dm_unregister_target (&cache_target); +if (!migration_cache)return -ENOMEM ; - } r =dm_register_target (&cache_target);if (r) {DMERR ("cache target registration failed: %d" , r); +kmem_cache_destroy (migration_cache);return r; }
Greg Kroah-Hartman
maintainerPATCH 122/135 dm: fix report zone remapping to account for partition offset
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 9864cd5dc54cade89fd4b0954c2e522841aa247c upstream.
If dm-linear or dm-flakey are layered on top of a partition of a zoned block device, remapping of the start sector and write pointer position of the zones reported by a report zones BIO must be modified to account for the target table entry mapping (start offset within the device and entry mapping with the dm device). If the target's backing device is a partition of a whole disk, the start sector on the physical device of the partition must also be accounted for when modifying the zone information. However, dm_remap_zone_report() was not considering this last case, resulting in incorrect zone information remapping with targets using disk partitions.
Fix this by calculating the target backing device start sector using the position of the completed report zones BIO and the unchanged position and size of the original report zone BIO. With this value calculated, the start sector and write pointer position of the target zones can be correctly remapped.
--- drivers/md/dm.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-)
drivers/md/dm.c +20 -7
@@ -1153,12 +1153,14 @@ void dm_accept_partial_bio(struct bio *bEXPORT_SYMBOL_GPL (dm_accept_partial_bio);/* -* The zone descriptors obtained with a zone report indicate -* zone positions within the target device. The zone descriptors -* must be remapped to match their position within the dm device. -* A target may call dm_remap_zone_report after completion of a -* REQ_OP_ZONE_REPORT bio to remap the zone descriptors obtained -* from the target device mapping to the dm device. +* The zone descriptors obtained with a zone report indicate zone positions +* within the target backing device, regardless of that device is a partition +* and regardless of the target mapping start sector on the device or partition. +* The zone descriptors start sector and write pointer position must be adjusted +* to match their relative position within the dm device. +* A target may call dm_remap_zone_report() after completion of a +* REQ_OP_ZONE_REPORT bio to remap the zone descriptors obtained from the +* backing device. */ void dm_remap_zone_report (struct dm_target *ti,struct bio *bio,sector_t start) {
@@ -1169,6 +1171,7 @@ void dm_remap_zone_report(struct dm_targstruct blk_zone *zone;unsigned int nr_rep =0 ;unsigned int ofst; +sector_t part_offset;struct bio_vec bvec;struct bvec_iter iter;void *addr;
@@ -1177,6 +1180,15 @@ void dm_remap_zone_report(struct dm_targreturn ;/* +* bio sector was incremented by the request size on completion. Taking +* into account the original request sector, the target start offset on +* the backing device and the target mapping offset (ti->begin), the +* start sector of the backing device. The partition offset is always 0 +* if the target uses a whole device. +*/ + part_offset = bio->bi_iter.bi_sector + ti->begin - (start +bio_end_sector (report_bio)); + +/* * Remap the start sector of the reported zones. For sequential zones, * also remap the write pointer position. */
@@ -1193,6 +1205,7 @@ void dm_remap_zone_report(struct dm_targ/* Set zones start sector */ while (hdr->nr_zones && ofst < bvec.bv_len) { zone = addr + ofst; + zone->start -= part_offset;if (zone->start >= start + ti->len) { hdr->nr_zones =0 ;break ;
@@ -1204,7 +1217,7 @@ void dm_remap_zone_report(struct dm_targelse if (zone->cond ==BLK_ZONE_COND_EMPTY ) zone->wp = zone->start;else - zone->wp = zone->wp + ti->begin - start; + zone->wp = zone->wp + ti->begin - start - part_offset; } ofst +=sizeof (struct blk_zone ); hdr->nr_zones--;
Greg Kroah-Hartman
maintainerPATCH 123/135 dm linear: eliminate linear_end_io call if CONFIG_DM_ZONED disabled
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Snitzer <[email protected]>
commit beb9caac211c1be1bc118bb62d5cf09c4107e6a5 upstream.
It is best to avoid any extra overhead associated with bio completion. DM core will indirectly call a DM target's .end_io if it is defined. In the case of DM linear, there is no need to do so (for every bio that completes) if CONFIG_DM_ZONED is not enabled.
Avoiding an extra indirect call for every bio completion is very important for ensuring DM linear doesn't incur more overhead that further widens the performance gap between dm-linear and raw block devices.
--- drivers/md/dm-linear.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/md/dm-linear.c +7 -1
@@ -102,6 +102,7 @@ static int linear_map(struct dm_target *return DM_MAPIO_REMAPPED ; } +#ifdef CONFIG_DM_ZONED static int linear_end_io (struct dm_target *ti,struct bio *bio,blk_status_t *error) {
@@ -112,6 +113,7 @@ static int linear_end_io(struct dm_targe return DM_ENDIO_DONE; } +#endif static void linear_status (struct dm_target *ti,status_type_t type,unsigned status_flags,char *result,unsigned maxlen)
@@ -208,12 +210,16 @@ static size_t linear_dax_copy_to_iter(ststatic struct target_type linear_target = { .name ="linear" , .version = {1 ,4 ,0 }, +#ifdef CONFIG_DM_ZONED + .end_io = linear_end_io, .features =DM_TARGET_PASSES_INTEGRITY |DM_TARGET_ZONED_HM , +#else + .features =DM_TARGET_PASSES_INTEGRITY , +#endif .module =THIS_MODULE , .ctr = linear_ctr, .dtr = linear_dtr, .map = linear_map, - .end_io = linear_end_io, .status = linear_status, .prepare_ioctl = linear_prepare_ioctl, .iterate_devices = linear_iterate_devices,
Greg Kroah-Hartman
maintainerPATCH 125/135 cgroup: Fix dom_cgrp propagation when enabling threaded mode
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit 479adb89a97b0a33e5a9d702119872cc82ca21aa upstream.
A cgroup which is already a threaded domain may be converted into a threaded cgroup if the prerequisite conditions are met. When this happens, all threaded descendant should also have their ->dom_cgrp updated to the new threaded domain cgroup. Unfortunately, this propagation was missing leading to the following failure.
# cd /sys/fs/cgroup/unified # cat cgroup.subtree_control # show that no controllers are enabled
# mkdir -p mycgrp/a/b/c # echo threaded > mycgrp/a/b/cgroup.type
At this point, the hierarchy looks as follows:
mycgrp [d] a [dt] b [t] c [inv]
Now let's make node "a" threaded (and thus "mycgrp" s made "domain threaded"):
# echo threaded > mycgrp/a/cgroup.type
By this point, we now have a hierarchy that looks as follows:
mycgrp [dt] a [t] b [t] c [inv]
But, when we try to convert the node "c" from "domain invalid" to "threaded", we get ENOTSUP on the write():
# echo threaded > mycgrp/a/b/c/cgroup.type sh: echo: write error: Operation not supported
This patch fixes the problem by
* Moving the opencoded ->dom_cgrp save and restoration in cgroup_enable_threaded() into cgroup_{save|restore}_control() so that mulitple cgroups can be handled.
* Updating all threaded descendants' ->dom_cgrp to point to the new dom_cgrp when enabling threaded mode.
--- include/linux/cgroup-defs.h | 1 + kernel/cgroup/cgroup.c | 25 ++++++++++++++++--------- 2 files changed, 17 insertions(+), 9 deletions(-)
include/linux/cgroup-defs.h +1 -0
@@ -412,6 +412,7 @@ struct cgroup {* specific task are charged to the dom_cgrp. */ struct cgroup *dom_cgrp; +struct cgroup *old_dom_cgrp;/* used while enabling threaded */ /* per-cpu recursive resource statistics */ struct cgroup_rstat_cpu __percpu *rstat_cpu;
kernel/cgroup/cgroup.c +16 -9
@@ -2833,11 +2833,12 @@ restart: }/** -* cgroup_save_control - save control masks of a subtree +* cgroup_save_control - save control masks and dom_cgrp of a subtree * @cgrp: root of the target subtree * -* Save ->subtree_control and ->subtree_ss_mask to the respective old_ -* prefixed fields for @cgrp's subtree including @cgrp itself. +* Save ->subtree_control, ->subtree_ss_mask and ->dom_cgrp to the +* respective old_ prefixed fields for @cgrp's subtree including @cgrp +* itself. */ static void cgroup_save_control (struct cgroup *cgrp) {
@@ -2847,6 +2848,7 @@ static void cgroup_save_control(struct ccgroup_for_each_live_descendant_pre (dsct, d_css, cgrp) { dsct->old_subtree_control = dsct->subtree_control; dsct->old_subtree_ss_mask = dsct->subtree_ss_mask; + dsct->old_dom_cgrp = dsct->dom_cgrp; } }
@@ -2872,11 +2874,12 @@ static void cgroup_propagate_control(str }/** -* cgroup_restore_control - restore control masks of a subtree +* cgroup_restore_control - restore control masks and dom_cgrp of a subtree * @cgrp: root of the target subtree * -* Restore ->subtree_control and ->subtree_ss_mask from the respective old_ -* prefixed fields for @cgrp's subtree including @cgrp itself. +* Restore ->subtree_control, ->subtree_ss_mask and ->dom_cgrp from the +* respective old_ prefixed fields for @cgrp's subtree including @cgrp +* itself. */ static void cgroup_restore_control (struct cgroup *cgrp) {
@@ -2886,6 +2889,7 @@ static void cgroup_restore_control(struccgroup_for_each_live_descendant_post (dsct, d_css, cgrp) { dsct->subtree_control = dsct->old_subtree_control; dsct->subtree_ss_mask = dsct->old_subtree_ss_mask; + dsct->dom_cgrp = dsct->old_dom_cgrp; } }
@@ -3193,6 +3197,8 @@ static int cgroup_enable_threaded(struct {struct cgroup *parent =cgroup_parent (cgrp);struct cgroup *dom_cgrp = parent->dom_cgrp; +struct cgroup *dsct; +struct cgroup_subsys_state *d_css;int ret;lockdep_assert_held (&cgroup_mutex);
@@ -3222,12 +3228,13 @@ static int cgroup_enable_threaded(struct*/ cgroup_save_control (cgrp); - cgrp->dom_cgrp = dom_cgrp; +cgroup_for_each_live_descendant_pre (dsct, d_css, cgrp) +if (dsct == cgrp ||cgroup_is_threaded (dsct)) + dsct->dom_cgrp = dom_cgrp; + ret =cgroup_apply_control (cgrp);if (!ret) parent->nr_threaded_children++; -else - cgrp->dom_cgrp = cgrp;cgroup_finalize_control (cgrp, ret);return ret;
Greg Kroah-Hartman
maintainerPATCH 126/135 Input: xpad - add support for Xbox1 PDP Camo series gamepad
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ramses Ramírez <[email protected]>
commit 9735082a7cbae572c2eabdc45acecc8c9fa0759b upstream.
The "Xbox One PDP Wired Controller - Camo series" has a different product-id than the regular PDP controller and the PDP stealth series, but it uses the same initialization sequence. This patch adds the product-id of the camo series to the structures that handle the other PDP Xbox One controllers.
--- drivers/input/joystick/xpad.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/input/joystick/xpad.c +3 -0
@@ -231,6 +231,7 @@ static const struct xpad_device { { 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, XTYPE_XBOXONE }, { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE }, { 0x0e6f, 0x02a4, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE }, + { 0x0e6f, 0x02a6, "PDP Wired Controller for Xbox One - Camo Series", 0, XTYPE_XBOXONE }, { 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 }, { 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, XTYPE_XBOXONE }, { 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
@@ -530,6 +531,8 @@ static const struct xboxone_init_packetXBOXONE_INIT_PKT (0x0e6f ,0x02ab , xboxone_pdp_init2),XBOXONE_INIT_PKT (0x0e6f ,0x02a4 , xboxone_pdp_init1),XBOXONE_INIT_PKT (0x0e6f ,0x02a4 , xboxone_pdp_init2), +XBOXONE_INIT_PKT (0x0e6f ,0x02a6 , xboxone_pdp_init1), +XBOXONE_INIT_PKT (0x0e6f ,0x02a6 , xboxone_pdp_init2),XBOXONE_INIT_PKT (0x24c6 ,0x541a , xboxone_rumblebegin_init),XBOXONE_INIT_PKT (0x24c6 ,0x542a , xboxone_rumblebegin_init), XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_rumblebegin_init),
Greg Kroah-Hartman
maintainerPATCH 127/135 drm/nouveau/drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <[email protected]>
commit e46368cf77f2cb6304c51d9ff5f147cfb7dc0074 upstream.
While we currently grab a runtime PM ref in nouveau's normal connector detection code, we apparently don't do this for MST. This means if we're in a scenario where the GPU is suspended and userspace attempts to do a connector probe on an MSTC connector, the probe will fail entirely due to the DP aux channel and GPU not being woken up:
[ 316.633489] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff [ 316.635713] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff [ 316.637785] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
...
So, grab a runtime PM ref here.
--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/dispnv50/disp.c +14 -1
@@ -875,9 +875,22 @@ static enum drm_connector_status nv50_mstc_detect(struct drm_connector *connector, bool force) {struct nv50_mstc *mstc =nv50_mstc (connector); +enum drm_connector_status conn_status; +int ret; +if (!mstc->port)return connector_status_disconnected; -return drm_dp_mst_detect_port (connector, mstc->port->mgr, mstc->port); + + ret =pm_runtime_get_sync (connector->dev->dev); +if (ret <0 && ret != -EACCES ) +return connector_status_disconnected; + + conn_status =drm_dp_mst_detect_port (connector, mstc->port->mgr, + mstc->port); + +pm_runtime_mark_last_busy (connector->dev->dev); +pm_runtime_put_autosuspend (connector->dev->dev); +return conn_status; } static void
Greg Kroah-Hartman
maintainerPATCH 128/135 mmc: block: avoid multiblock reads for the last sector in SPI mode
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Boot <[email protected]>
commit 41591b38f5f8f78344954b68582b5f00e56ffe61 upstream.
On some SD cards over SPI, reading with the multiblock read command the last sector will leave the card in a bad state.
Remove last sectors from the multiblock reading cmd.
--- drivers/mmc/core/block.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/mmc/core/block.c +10 -0
@@ -1371,6 +1371,16 @@ static void mmc_blk_data_prep(struct mmcif (brq->data.blocks >1 ) {/* +* Some SD cards in SPI mode return a CRC error or even lock up +* completely when trying to read the last block using a +* multiblock read command. +*/ +if (mmc_host_is_spi (card->host) && (rq_data_dir (req) ==READ ) && + (blk_rq_pos (req) +blk_rq_sectors (req) == +get_capacity (md->disk))) + brq->data.blocks--; + +/* * After a read error, we redo the request one sector * at a time in order to accurately determine which * sectors can be read successfully.
Quoted 1 line · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release.
Gave this a try since I have r8169 NICs. Applied over .14 and now running on three different machines. No observed regressions in dmesg or behaviour; all smooth sailing.
cheers!
Holger
RE: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
In reply to Greg Kroah-HartmanQuoted 88 lines
-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Greg Kroah-Hartman
Sent: Tuesday, October 16, 2018 1:06 PM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial number4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit
00d7ddba1143623b31bc2c15d18216e2da031b14]Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
Signed-off-by Stephen Hemminger <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++-----------------(quoted diff) +0
-1- 2 files changed, 36 insertions(+), 25 deletions(-)drivers/net/hyperv/netvsc.c +3
-0@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated; net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial; +netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,drivers/net/hyperv/netvsc_drv.c +0
-13@@ -1794,20 +1794,6 @@ out_unlock:rtnl_unlock (); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ -struct net_device_context *ndev_ctx; - -list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { -struct net_device *dev =hv_get_drvdata (ndev_ctx- >device_ctx); - -if (ether_addr_equal (mac, dev->perm_addr)) -return dev; - } - -return NULL ; -} -static struct net_device *get_netvsc_byref (struct net_device *vf_netdev) { struct net_device_context *net_device_ctx; @@ -1936,26 +1922,48@@ static void netvsc_vf_setup(struct
work_drivers/net/hyperv/netvsc_drv.c +14
-0rtnl_unlock (); } +/* Find netvsc by VMBus serial number. +* The PCI hyperv controller records the serial number as the slot. +*/ +static struct net_device *get_netvsc_byslot (const struct net_device +*vf_netdev) { +struct device *parent = vf_netdev->dev.parent; +struct net_device_context *ndev_ctx; +struct pci_dev *pdev; + +if (!parent || !dev_is_pci (parent)) +return NULL ;/* not a PCI device */ + + pdev =to_pci_dev (parent); +if (!pdev->slot) {
drivers/net/hyperv/netvsc_drv.c static void netvsc_vf_setup(struct work_ · line 1948
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +10
-0+netdev_notice (vf_netdev,"no PCI slot information\n" ); +return NULL ; + } + +list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { +if (!ndev_ctx->vf_alloc) +continue ; + +if (ndev_ctx->vf_serial == pdev->slot->number) +return hv_get_drvdata (ndev_ctx->device_ctx);
Greg,
I had a fix to this patch. If not already, Could you include my following fix together?hv_netvsc: fix vf serial matching with pci slot info
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5
Thanks,
- Haiyang
Re: [PATCH 4.18 079/135] Add tests for memory.oom.group
In reply to Greg Kroah-HartmanQuoted 1 line · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
Memory.oom.group has been merged into 4.19, so the test will fail on 4.18. I see no reasons to backport this patch, let's drop it.
Thanks!
Re: [PATCH 4.18 086/135] KVM: PPC: Book3S HV: Dont use compound_order to determine host mapping size
In reply to Greg Kroah-HartmanQuoted 7 lines · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
[ Upstream commit
71d29f43b6332badc5598c656616a62575e83342]
If you take 71d29f43b633 then you also need 6579804c4317 ("KVM: PPC:
Book3S HV: Avoid crash from THP collapse during radix page fault", 2018-10-04).
Thanks,
Paul.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
In reply to Haiyang ZhangQuoted 101 lines · Haiyang Zhang
Quoted 88 lines
-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Greg Kroah-Hartman
Sent: Tuesday, October 16, 2018 1:06 PM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial number4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit
00d7ddba1143623b31bc2c15d18216e2da031b14]Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
Signed-off-by Stephen Hemminger <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++-----------------(quoted diff) +0
-1- 2 files changed, 36 insertions(+), 25 deletions(-)drivers/net/hyperv/netvsc.c +3
-0@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated; net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial; +netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,drivers/net/hyperv/netvsc_drv.c +0
-13@@ -1794,20 +1794,6 @@ out_unlock:rtnl_unlock (); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ -struct net_device_context *ndev_ctx; - -list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { -struct net_device *dev =hv_get_drvdata (ndev_ctx- >device_ctx); - -if (ether_addr_equal (mac, dev->perm_addr)) -return dev; - } - -return NULL ; -} -static struct net_device *get_netvsc_byref (struct net_device *vf_netdev) { struct net_device_context *net_device_ctx; @@ -1936,26 +1922,48@@ static void netvsc_vf_setup(struct
work_drivers/net/hyperv/netvsc_drv.c +14
-0rtnl_unlock (); } +/* Find netvsc by VMBus serial number. +* The PCI hyperv controller records the serial number as the slot. +*/ +static struct net_device *get_netvsc_byslot (const struct net_device +*vf_netdev) { +struct device *parent = vf_netdev->dev.parent; +struct net_device_context *ndev_ctx; +struct pci_dev *pdev; + +if (!parent || !dev_is_pci (parent)) +return NULL ;/* not a PCI device */ + + pdev =to_pci_dev (parent); +if (!pdev->slot) {drivers/net/hyperv/netvsc_drv.c static void netvsc_vf_setup(struct work_ · line 1948
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +10
-0+netdev_notice (vf_netdev,"no PCI slot information\n" ); +return NULL ; + } + +list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { +if (!ndev_ctx->vf_alloc) +continue ; + +if (ndev_ctx->vf_serial == pdev->slot->number) +return hv_get_drvdata (ndev_ctx->device_ctx);Greg,
Quoted 3 lines
I had a fix to this patch. If not already, Could you include my following fix together?
hv_netvsc: fix vf serial matching with pci slot info
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5
I can not take a patch that is not "upstream" yet, sorry.
Also, this really feels like a "new feature" to me. Can someone explain what bug this is fixing?
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 079/135] Add tests for memory.oom.group
In reply to Roman GushchinQuoted 5 lines · Roman Gushchin
Quoted 1 line · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
Memory.oom.group has been merged into 4.19, so the test will fail on 4.18. I see no reasons to backport this patch, let's drop it.
Thanks for letting me know, now dropped.
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 086/135] KVM: PPC: Book3S HV: Dont use compound_order to determine host mapping size
In reply to Paul MackerrasQuoted 5 lines · Paul Mackerras
Quoted 4 lines · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 7 lines
Quoted 3 lines
From: Nicholas Piggin <[email protected]>
[ Upstream commit
71d29f43b6332badc5598c656616a62575e83342]If you take
71d29f43b633then you also need6579804c4317("KVM: PPC:
Book3S HV: Avoid crash from THP collapse during radix page fault", 2018-10-04).
Thanks, now queued up.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 6 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release.
Gave this a try since I have r8169 NICs. Applied over .14 and now running on three different machines. No observed regressions in dmesg or behaviour; all smooth sailing.
Wonderful, thanks for testing this and letting me know.
greg k-h
RE: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
In reply to Greg Kroah-HartmanQuoted 132 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Wednesday, October 17, 2018 3:46 AM
To: Haiyang Zhang <[email protected]>
Cc: [email protected]; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 27 lines · Haiyang Zhang
Quoted 27 lines
-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Greg Kroah-Hartman
Sent: Tuesday, October 16, 2018 1:06 PM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial number4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit
00d7ddba1143623b31bc2c15d18216e2da031b14]Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Stephen Hemminger <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++-----------------
Quoted 27 lines
Quoted 27 lines
(quoted diff) +0
-1- 2 files changed, 36 insertions(+), 25 deletions(-)drivers/net/hyperv/netvsc.c +3
-0@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated; net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial; +netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,drivers/net/hyperv/netvsc_drv.c +0
-5@@ -1794,20 +1794,6 @@ out_unlock:rtnl_unlock (); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ -struct net_device_context *ndev_ctx; - -list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { -struct net_device *dev =hv_get_drvdata (ndev_ctx- >device_ctx);Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c out_unlock:
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +0
-8- -if (ether_addr_equal (mac, dev->perm_addr)) -return dev; - } - -return NULL ; -} -static struct net_device *get_netvsc_byref (struct net_device *vf_netdev) { struct net_device_context *net_device_ctx; @@ -1936,26 +1922,48@@
Quoted 31 lines
Quoted 18 lines
static void netvsc_vf_setup(struct
work_drivers/net/hyperv/netvsc_drv.c +14
-0rtnl_unlock (); } +/* Find netvsc by VMBus serial number. +* The PCI hyperv controller records the serial number as the slot. +*/ +static struct net_device *get_netvsc_byslot (const struct net_device +*vf_netdev) { +struct device *parent = vf_netdev->dev.parent; +struct net_device_context *ndev_ctx; +struct pci_dev *pdev; + +if (!parent || !dev_is_pci (parent)) +return NULL ;/* not a PCI device */ + + pdev =to_pci_dev (parent); +if (!pdev->slot) {drivers/net/hyperv/netvsc_drv.c static void netvsc_vf_setup(struct work_ · line 1948
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +10
-0+netdev_notice (vf_netdev,"no PCI slot information\n" ); +return NULL ; + } + +list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { +if (!ndev_ctx->vf_alloc) +continue ; + +if (ndev_ctx->vf_serial == pdev->slot->number) +return hv_get_drvdata (ndev_ctx->device_ctx);Greg,
Quoted 1 line
I had a fix to this patch. If not already, Could you include my following fix
together?
Quoted 3 lines
hv_netvsc: fix vf serial matching with pci slot info
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k
ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fdavem%2Fnet-next.git%2F
Quoted 1 line
commit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&da ta=02%
Quoted 1 line
7C01%7Chaiyangz%40microsoft.com%7C6ce194a47449435fe82a08d63404a94e %7C7
Quoted 1 line
2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753591959679786& ;sdata
Quoted 1 line
Quoted 7 lines
=ReWYMZW%2FYtoFSbFSxny9VGw6V8v9J4sGanfJjbVd34A%3D&reserved= 0
I can not take a patch that is not "upstream" yet, sorry.
Also, this really feels like a "new feature" to me. Can someone explain what bug this is fixing?
Patch #A: hv_netvsc: pair VF based on serial number
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=00d7ddba1143623b31bc2c15d18216e2da031b14
Patch #B: hv_netvsc: fix vf serial matching with pci slot info
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5
The patch #A is a feature that use VF serial number for matching. But #A has a bug causing mismatch.
Patch #B, upstream now (see the link to Linux-next), is a fix to #A.
So, if #A is ported to 4.18, we need to port #B together. Otherwise, not porting both the #A and #B is also fine.
Thanks,
- Haiyang
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
Quoted 143 lines · Haiyang Zhang
Quoted 132 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Wednesday, October 17, 2018 3:46 AM
To: Haiyang Zhang <[email protected]>
Cc: [email protected]; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 27 lines · Haiyang Zhang
Quoted 27 lines
-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Greg Kroah-Hartman
Sent: Tuesday, October 16, 2018 1:06 PM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial number4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit
00d7ddba1143623b31bc2c15d18216e2da031b14]Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
Quoted 7 lines
Quoted 7 lines
Signed-off-by Stephen Hemminger <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++-----------------
Quoted 27 lines
Quoted 27 lines
(quoted diff) +0
-1- 2 files changed, 36 insertions(+), 25 deletions(-)drivers/net/hyperv/netvsc.c +3
-0@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated; net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial; +netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,drivers/net/hyperv/netvsc_drv.c +0
-5@@ -1794,20 +1794,6 @@ out_unlock:rtnl_unlock (); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ -struct net_device_context *ndev_ctx; - -list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { -struct net_device *dev =hv_get_drvdata (ndev_ctx- >device_ctx);Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c out_unlock:
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +0
-8- -if (ether_addr_equal (mac, dev->perm_addr)) -return dev; - } - -return NULL ; -} -static struct net_device *get_netvsc_byref (struct net_device *vf_netdev) { struct net_device_context *net_device_ctx; @@ -1936,26 +1922,48@@
Quoted 31 lines
Quoted 18 lines
static void netvsc_vf_setup(struct
work_drivers/net/hyperv/netvsc_drv.c +14
-0rtnl_unlock (); } +/* Find netvsc by VMBus serial number. +* The PCI hyperv controller records the serial number as the slot. +*/ +static struct net_device *get_netvsc_byslot (const struct net_device +*vf_netdev) { +struct device *parent = vf_netdev->dev.parent; +struct net_device_context *ndev_ctx; +struct pci_dev *pdev; + +if (!parent || !dev_is_pci (parent)) +return NULL ;/* not a PCI device */ + + pdev =to_pci_dev (parent); +if (!pdev->slot) {drivers/net/hyperv/netvsc_drv.c static void netvsc_vf_setup(struct work_ · line 1948
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +10
-0+netdev_notice (vf_netdev,"no PCI slot information\n" ); +return NULL ; + } + +list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { +if (!ndev_ctx->vf_alloc) +continue ; + +if (ndev_ctx->vf_serial == pdev->slot->number) +return hv_get_drvdata (ndev_ctx->device_ctx);Greg,
Quoted 1 line
I had a fix to this patch. If not already, Could you include my following fix
together?
Quoted 3 lines
hv_netvsc: fix vf serial matching with pci slot info
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k
ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fdavem%2Fnet-next.git%2F
Quoted 1 line
commit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&da ta=02%
Quoted 1 line
7C01%7Chaiyangz%40microsoft.com%7C6ce194a47449435fe82a08d63404a94e %7C7
Quoted 1 line
2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753591959679786& ;sdata
Quoted 1 line
Quoted 7 lines
=ReWYMZW%2FYtoFSbFSxny9VGw6V8v9J4sGanfJjbVd34A%3D&reserved= 0
I can not take a patch that is not "upstream" yet, sorry.
Also, this really feels like a "new feature" to me. Can someone explain what bug this is fixing?
Patch #A:
hv_netvsc: pair VF based on serial number
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=00d7ddba1143623b31bc2c15d18216e2da031b14
Quoted 6 lines
Patch #B:
hv_netvsc: fix vf serial matching with pci slot info
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5The patch #A is a feature that use VF serial number for matching. But #A has a bug causing mismatch.
Patch #B, upstream now (see the link to Linux-next), is a fix to #A.
linux-next is not "upstream", it needs to be in Linus's tree, you know this :(
Quoted 1 line
So, if #A is ported to 4.18, we need to port #B together. Otherwise, not porting both the #A and #B is also fine.
You didn't answer my original question here, what bug is this fixing?
I'll go drop this from the tree for now anyway...
thanks,
greg k-h
Sasha Levin
maintainerRe: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
In reply to Greg Kroah-HartmanQuoted 2 lines · Greg Kroah-Hartman
Also, this really feels like a "new feature" to me. Can someone explain what bug this is fixing?
Reading the commit log/code it seems that it was possible for 2 (or more) synthetic devices to have the same MAC address even though the current code treats them as unique and uses it as a lookup index.
Let me confirm with Stephen. This came through the regular AUTOSEL process and I don't really know more about this patch than you do at this point.
--
Thanks,
Sasha
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release. There are 135 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 Thu Oct 18 17:04:43 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.18.15-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: 62569d12d9372bc0c50a04fe8923c47fd89435fc
git describe: v4.18.14-136-g62569d12d937
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.14-136-g62569d12d937
No regressions (compared to build v4.18.14)
No fixes (compared to build v4.18.14)
Ran 21140 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-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-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
RE: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
In reply to Greg Kroah-HartmanQuoted 193 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Wednesday, October 17, 2018 9:17 AM
To: Haiyang Zhang <[email protected]>
Cc: [email protected]; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 27 lines · Haiyang Zhang
Quoted 27 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Wednesday, October 17, 2018 3:46 AM
To: Haiyang Zhang <[email protected]>
Cc: [email protected]; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 14 lines · Haiyang Zhang
Quoted 14 lines
-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Greg Kroah-Hartman
Sent: Tuesday, October 16, 2018 1:06 PM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
4.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit
00d7ddba1143623b31bc2c15d18216e2da031b14]Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Signed-off-by Stephen Hemminger <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++------------
Quoted 30 lines
Quoted 9 lines
-----
Quoted 8 lines
drivers/net/hyperv/netvsc.c static void netvsc_send_vf(struct net_de · line 1204
Quoted 8 lines
(quoted diff) +0
-1- 2 files changed, 36 insertions(+), 25 deletions(-)drivers/net/hyperv/netvsc.c +0
-0@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg-msg.v4_msg.vf_assoc.allocated;
Quoted 1 line
Quoted 1 line
drivers/net/hyperv/netvsc.c static void netvsc_send_vf(struct net_de · line 1205
Quoted 1 line
drivers/net/hyperv/netvsc.c +0
-0net_device_ctx->vf_serial = nvmsg-msg.v4_msg.vf_assoc.serial;
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
drivers/net/hyperv/netvsc.c +3
-0+netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,drivers/net/hyperv/netvsc_drv.c +0
-5@@ -1794,20 +1794,6 @@ out_unlock:rtnl_unlock (); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ -struct net_device_context *ndev_ctx; - -list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { -struct net_device *dev =hv_get_drvdata (ndev_ctx- >device_ctx);Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
drivers/net/hyperv/netvsc_drv.c out_unlock:
Quoted 9 lines
drivers/net/hyperv/netvsc_drv.c +0
-8- -if (ether_addr_equal (mac, dev->perm_addr)) -return dev; - } - -return NULL ; -} - static struct net_device *get_netvsc_byref(struct net_device
*vf_netdev) {Quoted 37 lines
Quoted 37 lines
Quoted 2 lines
drivers/net/hyperv/netvsc_drv.c out_unlock:
Quoted 2 lines
drivers/net/hyperv/netvsc_drv.c +1
-0struct net_device_context *net_device_ctx; @@ -1936,26 +1922 ,48 @@
Quoted 34 lines
Quoted 19 lines
static void netvsc_vf_setup(struct
work_drivers/net/hyperv/netvsc_drv.c +15
-0rtnl_unlock (); } +/* Find netvsc by VMBus serial number. +* The PCI hyperv controller records the serial number as the slot. +*/ +static struct net_device *get_netvsc_byslot (const struct +net_device +*vf_netdev) { +struct device *parent = vf_netdev->dev.parent; +struct net_device_context *ndev_ctx; +struct pci_dev *pdev; + +if (!parent || !dev_is_pci (parent)) +return NULL ;/* not a PCI device */ + + pdev =to_pci_dev (parent); +if (!pdev->slot) {drivers/net/hyperv/netvsc_drv.c static void netvsc_vf_setup(struct work_ · line 1948
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +10
-0+netdev_notice (vf_netdev,"no PCI slot information\n" ); +return NULL ; + } + +list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { +if (!ndev_ctx->vf_alloc) +continue ; + +if (ndev_ctx->vf_serial == pdev->slot->number) +return hv_get_drvdata (ndev_ctx->device_ctx);Greg,
I had a fix to this patch. If not already, Could you include my following fix
Quoted 8 lines
Quoted 8 lines
together?
Quoted 4 lines
hv_netvsc: fix vf serial matching with pci slot info
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
it.k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fdavem%2Fnet-next.git%2F
Quoted 1 line
commit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&da
Quoted 3 lines
Quoted 3 lines
ta=02%
Quoted 1 line
7C01%7Chaiyangz%40microsoft.com%7C6ce194a47449435fe82a08d63404a94e
Quoted 3 lines
Quoted 3 lines
%7C7
Quoted 1 line
2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753591959679786&
Quoted 3 lines
Quoted 3 lines
;sdata
Quoted 1 line
=ReWYMZW%2FYtoFSbFSxny9VGw6V8v9J4sGanfJjbVd34A%3D&reserved=
Quoted 10 lines
Quoted 6 lines
0
I can not take a patch that is not "upstream" yet, sorry.
Also, this really feels like a "new feature" to me. Can someone explain what bug this is fixing?
Patch #A:
hv_netvsc: pair VF based on serial number
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k
ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git%2
Quoted 1 line
Fcommit%2F%3Fid%3D00d7ddba1143623b31bc2c15d18216e2da031b14& data=02
Quoted 1 line
%7C01%7Chaiyangz%40microsoft.com%7C2e07aa3f8a9d4f32526008d63432d
f14%7C
Quoted 1 line
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753790439794786&am p;sdat
Quoted 5 lines
a=0ZyQ7jJdgsEZbh8TqA0eypvPUJVQaxSJcSNYuhLSl%2Fc%3D&reserved=0
Patch #B:
hv_netvsc: fix vf serial matching with pci slot info
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k
ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git%2
Quoted 1 line
Fcommit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&d ata=02
Quoted 1 line
%7C01%7Chaiyangz%40microsoft.com%7C2e07aa3f8a9d4f32526008d63432d
f14%7C
Quoted 1 line
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753790439794786&am p;sdat
Quoted 1 line
Quoted 8 lines
a=JPfFlatrkt1K6zMLHmZDRG51cCLwVk9pXqHVtLm26hA%3D&reserved=0
Quoted 2 lines
The patch #A is a feature that use VF serial number for matching. But #A has
a bug causing mismatch.
Quoted 2 lines
Patch #B, upstream now (see the link to Linux-next), is a fix to #A.
You didn't answer my original question here, what bug is this fixing?
Patch #A: hv_netvsc: pair VF based on serial number
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=00d7ddba1143623b31bc2c15d18216e2da031b14
Patch #B: hv_netvsc: fix vf serial matching with pci slot info
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5
The VF NIC needs to be paired with synthetic NIC on HyperV -- to do that we use MAC address matching before the patch #A. But a non VF NIC can also have the same MAC, which shouldn't be paired with synthetic NIC. So a better method is implemented by #A to use VF serial number for matching.
But, #A has a bug, which causes matching to fail. Patch #B fixed it by extracting the VF serial number correctly from slot info.
Thanks,
- Haiyang
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
Quoted 208 lines · Haiyang Zhang
Quoted 193 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Wednesday, October 17, 2018 9:17 AM
To: Haiyang Zhang <[email protected]>
Cc: [email protected]; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 27 lines · Haiyang Zhang
Quoted 27 lines
-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Wednesday, October 17, 2018 3:46 AM
To: Haiyang Zhang <[email protected]>
Cc: [email protected]; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 14 lines · Haiyang Zhang
Quoted 14 lines
-----Original Message-----
From: [email protected] <linux-kernel- [email protected]> On Behalf Of Greg Kroah-Hartman
Sent: Tuesday, October 16, 2018 1:06 PM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Stephen Hemminger <[email protected]>; David S. Miller <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 101/135]hv_netvsc: pair VF based on serial numberQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
4.18-stable review patch. If anyone has any objections, please let me
know.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit
00d7ddba1143623b31bc2c15d18216e2da031b14]Matching network device based on MAC address is problematic since a non VF network device can be creted with a duplicate MAC address causing confusion and problems. The VMBus API does provide a serial number that is a better matching method.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Signed-off-by Stephen Hemminger <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/net/hyperv/netvsc.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++------------
Quoted 30 lines
Quoted 9 lines
-----
Quoted 8 lines
drivers/net/hyperv/netvsc.c static void netvsc_send_vf(struct net_de · line 1204
Quoted 8 lines
(quoted diff) +0
-1- 2 files changed, 36 insertions(+), 25 deletions(-)drivers/net/hyperv/netvsc.c +0
-0@@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de net_device_ctx->vf_alloc = nvmsg-msg.v4_msg.vf_assoc.allocated;
Quoted 1 line
Quoted 1 line
drivers/net/hyperv/netvsc.c static void netvsc_send_vf(struct net_de · line 1205
Quoted 1 line
drivers/net/hyperv/netvsc.c +0
-0net_device_ctx->vf_serial = nvmsg-msg.v4_msg.vf_assoc.serial;
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
drivers/net/hyperv/netvsc.c +3
-0+netdev_info (ndev,"VF slot %u %s\n" , + net_device_ctx->vf_serial, + net_device_ctx->vf_alloc ?"added" :"removed" ); } static void netvsc_receive_inband(struct net_device *ndev,drivers/net/hyperv/netvsc_drv.c +0
-5@@ -1794,20 +1794,6 @@ out_unlock:rtnl_unlock (); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ -struct net_device_context *ndev_ctx; - -list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { -struct net_device *dev =hv_get_drvdata (ndev_ctx- >device_ctx);Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
drivers/net/hyperv/netvsc_drv.c out_unlock:
Quoted 9 lines
drivers/net/hyperv/netvsc_drv.c +0
-8- -if (ether_addr_equal (mac, dev->perm_addr)) -return dev; - } - -return NULL ; -} - static struct net_device *get_netvsc_byref(struct net_device
*vf_netdev) {Quoted 37 lines
Quoted 37 lines
Quoted 2 lines
drivers/net/hyperv/netvsc_drv.c out_unlock:
Quoted 2 lines
drivers/net/hyperv/netvsc_drv.c +1
-0struct net_device_context *net_device_ctx; @@ -1936,26 +1922 ,48 @@
Quoted 34 lines
Quoted 19 lines
static void netvsc_vf_setup(struct
work_drivers/net/hyperv/netvsc_drv.c +15
-0rtnl_unlock (); } +/* Find netvsc by VMBus serial number. +* The PCI hyperv controller records the serial number as the slot. +*/ +static struct net_device *get_netvsc_byslot (const struct +net_device +*vf_netdev) { +struct device *parent = vf_netdev->dev.parent; +struct net_device_context *ndev_ctx; +struct pci_dev *pdev; + +if (!parent || !dev_is_pci (parent)) +return NULL ;/* not a PCI device */ + + pdev =to_pci_dev (parent); +if (!pdev->slot) {drivers/net/hyperv/netvsc_drv.c static void netvsc_vf_setup(struct work_ · line 1948
Quoted 10 lines
drivers/net/hyperv/netvsc_drv.c +10
-0+netdev_notice (vf_netdev,"no PCI slot information\n" ); +return NULL ; + } + +list_for_each_entry (ndev_ctx, &netvsc_dev_list, list) { +if (!ndev_ctx->vf_alloc) +continue ; + +if (ndev_ctx->vf_serial == pdev->slot->number) +return hv_get_drvdata (ndev_ctx->device_ctx);Greg,
I had a fix to this patch. If not already, Could you include my following fix
Quoted 8 lines
Quoted 8 lines
together?
Quoted 4 lines
hv_netvsc: fix vf serial matching with pci slot info
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
it.k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fdavem%2Fnet-next.git%2F
Quoted 1 line
commit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&da
Quoted 3 lines
Quoted 3 lines
ta=02%
Quoted 1 line
7C01%7Chaiyangz%40microsoft.com%7C6ce194a47449435fe82a08d63404a94e
Quoted 3 lines
Quoted 3 lines
%7C7
Quoted 1 line
2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753591959679786&
Quoted 3 lines
Quoted 3 lines
;sdata
Quoted 1 line
=ReWYMZW%2FYtoFSbFSxny9VGw6V8v9J4sGanfJjbVd34A%3D&reserved=
Quoted 10 lines
Quoted 6 lines
0
I can not take a patch that is not "upstream" yet, sorry.
Also, this really feels like a "new feature" to me. Can someone explain what bug this is fixing?
Patch #A:
hv_netvsc: pair VF based on serial number
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k
ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git%2
Quoted 1 line
Fcommit%2F%3Fid%3D00d7ddba1143623b31bc2c15d18216e2da031b14& data=02
Quoted 1 line
%7C01%7Chaiyangz%40microsoft.com%7C2e07aa3f8a9d4f32526008d63432d
f14%7C
Quoted 1 line
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753790439794786&am p;sdat
Quoted 5 lines
a=0ZyQ7jJdgsEZbh8TqA0eypvPUJVQaxSJcSNYuhLSl%2Fc%3D&reserved=0
Patch #B:
hv_netvsc: fix vf serial matching with pci slot info
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k
ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git%2
Quoted 1 line
Fcommit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&d ata=02
Quoted 1 line
%7C01%7Chaiyangz%40microsoft.com%7C2e07aa3f8a9d4f32526008d63432d
f14%7C
Quoted 1 line
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753790439794786&am p;sdat
Quoted 1 line
Quoted 8 lines
a=JPfFlatrkt1K6zMLHmZDRG51cCLwVk9pXqHVtLm26hA%3D&reserved=0
Quoted 2 lines
The patch #A is a feature that use VF serial number for matching. But #A has
a bug causing mismatch.
Quoted 2 lines
Patch #B, upstream now (see the link to Linux-next), is a fix to #A.
You didn't answer my original question here, what bug is this fixing?
Patch #A:
hv_netvsc: pair VF based on serial number
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=00d7ddba1143623b31bc2c15d18216e2da031b14Patch #B:
hv_netvsc: fix vf serial matching with pci slot info
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5
Quoted 7 lines
The VF NIC needs to be paired with synthetic NIC on HyperV -- to do that we use MAC address matching before the patch #A. But a non VF NIC can also have the same MAC, which shouldn't be paired with synthetic NIC. So a better method is implemented by #A to use VF serial number for matching.
But, #A has a bug, which causes matching to fail. Patch #B fixed it by extracting the VF serial number correctly from slot info.
My question is, "what bug is patch #A fixing"? Somehow things have been working just fine for people without this, right? Remember, new features should not be backported to stable kernels if at all possible.
thanks,
greg k-h
Sasha Levin
maintainerRe: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Haiyang Zhang
The VF NIC needs to be paired with synthetic NIC on HyperV -- to do that we use MAC address matching before the patch #A. But a non VF NIC can also have the same MAC, which shouldn't be paired with synthetic NIC. So a better method is implemented by #A to use VF serial number for matching.
Quoted 6 lines
Quoted 2 lines
But, #A has a bug, which causes matching to fail. Patch #B fixed it by extracting the VF serial number correctly from slot info.
My question is, "what bug is patch #A fixing"? Somehow things have been working just fine for people without this, right? Remember, new features should not be backported to stable kernels if at all possible.
The current mechanism works fine most of the time, the problem is that once in a while we'd see collisions between the synthetic device MAC address and a different network device such as a bond device or just a regular non-VF network device.
So while in most cases assuming that MAC is unique and looking up devices based on it works, there's no guarantee that it's unique so this assumption isn't true and things break.
This is why it (usually) works now, but still has a bug that needs fixing.
If that makes sense, I'll requeue it when the fixes have soaked upstream for a few weeks.
--
Thanks,
Sasha
Greg Kroah-Hartman
maintainerRe: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number
Quoted 23 lines · Sasha Levin
Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Haiyang Zhang
The VF NIC needs to be paired with synthetic NIC on HyperV -- to do that we use MAC address matching before the patch #A. But a non VF NIC can also have the same MAC, which shouldn't be paired with synthetic NIC. So a better method is implemented by #A to use VF serial number for matching.
Quoted 6 lines
Quoted 2 lines
But, #A has a bug, which causes matching to fail. Patch #B fixed it by extracting the VF serial number correctly from slot info.
My question is, "what bug is patch #A fixing"? Somehow things have been working just fine for people without this, right? Remember, new features should not be backported to stable kernels if at all possible.
The current mechanism works fine most of the time, the problem is that once in a while we'd see collisions between the synthetic device MAC address and a different network device such as a bond device or just a regular non-VF network device.
So while in most cases assuming that MAC is unique and looking up devices based on it works, there's no guarantee that it's unique so this assumption isn't true and things break.
Quoted 5 lines
This is why it (usually) works now, but still has a bug that needs fixing.
If that makes sense, I'll requeue it when the fixes have soaked upstream for a few weeks.
That does, thanks, it should have been in the first patch's original changelog comments :)
So when both are upstream, feel free to resend.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerQuoted 11 lines · Dan Rue
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release. There are 135 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 Thu Oct 18 17:04:43 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Wonderful, thanks for testing and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release. There are 135 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 Thu Oct 18 17:04:43 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release. There are 135 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 Thu Oct 18 17:04:43 UTC 2018. Anything received after that time might be too late.
For v4.18.14-136-g56f5edd347f5:
Build results:
total: 136 pass: 136 fail: 0 Qemu test results: total: 321 pass: 321 fail: 0
Details are available at https://kerneltests.org/builders/.
Guenter
Greg Kroah-Hartman
maintainerQuoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.15 release. There are 135 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 Thu Oct 18 17:04:43 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all three of these and letting me know.
greg k-h