OSDN Git Service
Linus Torvalds [Fri, 31 May 2019 15:31:45 +0000 (08:31 -0700)]
Merge tag 'staging-5.2-rc3' of git://git./linux/kernel/git/gregkh/staging
Pull staging and IIO driver fixes from Greg KH:
"Here are some Staging and IIO driver fixes to resolve some reported
problems for 5.2-rc3.
Nothing major here, just some tiny changes, full details are in the
shortlog.
All have been in linux-next for a while with no reported issues"
* tag 'staging-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: kpc2000: Add dependency on MFD_CORE to kconfig symbol 'KPC2000'
staging: wilc1000: Fix some double unlock bugs in wilc_wlan_cleanup()
staging: vc04_services: prevent integer overflow in create_pagelist()
Staging: vc04_services: Fix a couple error codes
staging: wlan-ng: fix adapter initialization failure
staging: kpc2000: double unlock in error handling in kpc_dma_transfer()
staging: kpc2000: Fix build error without CONFIG_UIO
staging: kpc2000: fix build error on xtensa
staging: erofs: set sb->s_root to NULL when failing from __getname()
iio: adc: ti-ads8688: fix timestamp is not updated in buffer
iio: dac: ds4422/ds4424 fix chip verification
iio: imu: mpu6050: Fix FIFO layout for ICM20602
iio: adc: ads124: avoid buffer overflow
iio: adc: modify NPCM ADC read reference voltage
Linus Torvalds [Fri, 31 May 2019 15:28:44 +0000 (08:28 -0700)]
Merge tag 'tty-5.2-rc3' of git://git./linux/kernel/git/gregkh/tty
Pull tty/serial driver fixes from Greg KH:
"Here are some small serial and TTY driver fixes for 5.2-rc3.
Nothing major, just a number of fixes for reported issues. The fbcon
core fix also resolves an issue, and was acked by the relevant
maintainer to go through this tree.
All of these have been in linux-next with no reported issues"
* tag 'tty-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
vt/fbcon: deinitialize resources in visual_init() after failed memory allocation
tty: max310x: Fix external crystal register setup
serial: sh-sci: disable DMA for uart_console
serial: imx: remove log spamming error message
tty: serial: msm_serial: Fix XON/XOFF
Linus Torvalds [Fri, 31 May 2019 15:16:31 +0000 (08:16 -0700)]
Merge tag 'usb-5.2-rc3' of git://git./linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some tiny USB fixes for a number of reported issues for
5.2-rc3.
Nothing huge here, just a small collection of xhci and other driver
bugs that syzbot has been finding in some drivers. There is also a
usbip fix and a fix for the usbip fix in here :)
All have been in linux-next with no reported issues"
* tag 'usb-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usbip: usbip_host: fix stub_dev lock context imbalance regression
media: smsusb: better handle optional alignment
xhci: Use %zu for printing size_t type
xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()
xhci: Fix immediate data transfer if buffer is already DMA mapped
usb: xhci: avoid null pointer deref when bos field is NULL
usb: xhci: Fix a potential null pointer dereference in xhci_debugfs_create_endpoint()
xhci: update bounce buffer with correct sg num
media: usb: siano: Fix false-positive "uninitialized variable" warning
USB: rio500: update Documentation
USB: rio500: simplify locking
USB: rio500: fix memory leak in close after disconnect
USB: rio500: refuse more than one device at a time
usbip: usbip_host: fix BUG: sleeping function called from invalid context
USB: sisusbvga: fix oops in error path of sisusb_probe
USB: Add LPM quirk for Surface Dock GigE adapter
media: usb: siano: Fix general protection fault in smsusb
usb: mtu3: fix up undefined reference to usb_debug_root
USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor
Linus Torvalds [Fri, 31 May 2019 15:14:16 +0000 (08:14 -0700)]
Merge tag 'drm-fixes-2019-05-31' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Nothing too crazy, pretty quiet, maybe too quiet.
amdgpu:
- a fixed version of the raven firmware fix we previously reverted
- stolen memory fix
imx:
- regression fix
qxl:
- remove a bad warning
etnaviv:
- VM locking fix"
* tag 'drm-fixes-2019-05-31' of git://anongit.freedesktop.org/drm/drm:
drm/amdgpu: reserve stollen vram for raven series
drm/etnaviv: lock MMU while dumping core
drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q
drm/qxl: drop WARN_ONCE()
drm/amd/display: Don't load DMCU for Raven 1 (v2)
Linus Torvalds [Fri, 31 May 2019 04:11:22 +0000 (21:11 -0700)]
Merge git://git./linux/kernel/git/davem/net
Pull networking fixes from David Miller:
1) Fix OOPS during nf_tables rule dump, from Florian Westphal.
2) Use after free in ip_vs_in, from Yue Haibing.
3) Fix various kTLS bugs (NULL deref during device removal resync,
netdev notification ignoring, etc.) From Jakub Kicinski.
4) Fix ipv6 redirects with VRF, from David Ahern.
5) Memory leak fix in igmpv3_del_delrec(), from Eric Dumazet.
6) Missing memory allocation failure check in ip6_ra_control(), from
Gen Zhang. And likewise fix ip_ra_control().
7) TX clean budget logic error in aquantia, from Igor Russkikh.
8) SKB leak in llc_build_and_send_ui_pkt(), from Eric Dumazet.
9) Double frees in mlx5, from Parav Pandit.
10) Fix lost MAC address in r8169 during PCI D3, from Heiner Kallweit.
11) Fix botched register access in mvpp2, from Antoine Tenart.
12) Use after free in napi_gro_frags(), from Eric Dumazet.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (89 commits)
net: correct zerocopy refcnt with udp MSG_MORE
ethtool: Check for vlan etype or vlan tci when parsing flow_rule
net: don't clear sock->sk early to avoid trouble in strparser
net-gro: fix use-after-free read in napi_gro_frags()
net: dsa: tag_8021q: Create a stable binary format
net: dsa: tag_8021q: Change order of rx_vid setup
net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value
ipv4: tcp_input: fix stack out of bounds when parsing TCP options.
mlxsw: spectrum: Prevent force of 56G
mlxsw: spectrum_acl: Avoid warning after identical rules insertion
net: dsa: mv88e6xxx: fix handling of upper half of STATS_TYPE_PORT
r8169: fix MAC address being lost in PCI D3
net: core: support XDP generic on stacked devices.
netvsc: unshare skb in VF rx handler
udp: Avoid post-GRO UDP checksum recalculation
net: phy: dp83867: Set up RGMII TX delay
net: phy: dp83867: do not call config_init twice
net: phy: dp83867: increase SGMII autoneg timer duration
net: phy: dp83867: fix speed 10 in sgmii mode
net: phy: marvell10g: report if the PHY fails to boot firmware
...
Linus Torvalds [Fri, 31 May 2019 04:05:23 +0000 (21:05 -0700)]
Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The fixes are still trickling in for arm64, but the only really
significant one here is actually fixing a regression in the botched
module relocation range checking merged for -rc2.
Hopefully we've nailed it this time.
- Fix implementation of our set_personality() system call, which
wasn't being wrapped properly
- Fix system call function types to keep CFI happy
- Fix siginfo layout when delivering SIGKILL after a kernel fault
- Really fix module relocation range checking"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: use the correct function type for __arm64_sys_ni_syscall
arm64: use the correct function type in SYSCALL_DEFINE0
arm64: fix syscall_fn_t type
signal/arm64: Use force_sig not force_sig_fault for SIGKILL
arm64/module: revert to unsigned interpretation of ABS16/32 relocations
arm64: Fix the arm64_personality() syscall wrapper redirection
Linus Torvalds [Fri, 31 May 2019 03:52:40 +0000 (20:52 -0700)]
Merge tag 'for-5.2-rc2-tag' of git://git./linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"A few more fixes for bugs reported by users, fuzzing tools and
regressions:
- fix crashes in relocation:
+ resuming interrupted balance operation does not properly clean
up orphan trees
+ with enabled qgroups, resuming needs to be more careful about
block groups due to limited context when updating qgroups
- fsync and logging fixes found by fuzzing
- incremental send fixes for no-holes and clone
- fix spin lock type used in timer function for zstd"
* tag 'for-5.2-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
Btrfs: fix race updating log root item during fsync
Btrfs: fix wrong ctime and mtime of a directory after log replay
Btrfs: fix fsync not persisting changed attributes of a directory
btrfs: qgroup: Check bg while resuming relocation to avoid NULL pointer dereference
btrfs: reloc: Also queue orphan reloc tree for cleanup to avoid BUG_ON()
Btrfs: incremental send, fix emission of invalid clone operations
Btrfs: incremental send, fix file corruption when no-holes feature is enabled
btrfs: correct zstd workspace manager lock to use spin_lock_bh()
btrfs: Ensure replaced device doesn't have pending chunk allocation
Linus Torvalds [Fri, 31 May 2019 03:35:48 +0000 (20:35 -0700)]
Merge tag 'configfs-for-5.2-2' of git://git.infradead.org/users/hch/configfs
Pull configs fix from Christoph Hellwig:
- fix a use after free in configfs_d_iput (Sahitya Tummala)
* tag 'configfs-for-5.2-2' of git://git.infradead.org/users/hch/configfs:
configfs: Fix use-after-free when accessing sd->s_dentry
Linus Torvalds [Fri, 31 May 2019 02:58:59 +0000 (19:58 -0700)]
Merge tag 'sound-5.2-rc3' of git://git./linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"No big surprises here, just a few device-specific fixes.
HD-audio received several fixes for Acer, Dell, Huawei and other
laptops as well as the workaround for the new Intel chipset. One
significant one-liner fix is the disablement of the node-power saving
on Realtek codecs, which may potentially cover annoying bugs like the
background noises or click noises on many devices.
Other than that, a fix for FireWire bit definitions, and another fix
for LINE6 USB audio bug that was discovered by syzkaller"
* tag 'sound-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: fireface: Use ULL suffixes for 64-bit constants
ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops
ALSA: line6: Assure canceling delayed work at disconnection
ALSA: hda - Force polling mode on CNL for fixing codec communication
ALSA: hda/realtek - Enable micmute LED for Huawei laptops
ALSA: hda/realtek - Set default power save node to 0
ALSA: hda/realtek - Check headset type by unplug and resume
Linus Torvalds [Thu, 30 May 2019 23:33:37 +0000 (16:33 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git./linux/kernel/git/clk/linux
Pull clk driver fixes from Stephen Boyd:
- Don't expose the SiFive clk driver on non-RISCV architectures
- Fix some bits describing clks in the imx8mm driver
- Always call clk domain code in the TI driver so non-legacy platforms
work
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: ti: clkctrl: Fix clkdm_clk handling
clk: imx: imx8mm: fix int pll clk gate
clk: sifive: restrict Kconfig scope for the FU540 PRCI driver
Dave Airlie [Thu, 30 May 2019 23:15:14 +0000 (09:15 +1000)]
Merge tag 'imx-drm-fixes-2019-05-29' of git://git.pengutronix.de/git/pza/linux into drm-fixes
drm/imx: ipuv3-plane: fix frame rate regression on non-plus i.MX6Q
Fix a regression introduced by
70e8a0c71e9 ("drm/imx: ipuv3-plane: add
function to query atomic update status") that halves the frame rate on
non-plus i.MX6Q, because the pending check always returns "pending"
even if an update is actually applied.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1559128738.3651.4.camel@pengutronix.de
Willem de Bruijn [Thu, 30 May 2019 22:01:21 +0000 (18:01 -0400)]
net: correct zerocopy refcnt with udp MSG_MORE
TCP zerocopy takes a uarg reference for every skb, plus one for the
tcp_sendmsg_locked datapath temporarily, to avoid reaching refcnt zero
as it builds, sends and frees skbs inside its inner loop.
UDP and RAW zerocopy do not send inside the inner loop so do not need
the extra sock_zerocopy_get + sock_zerocopy_put pair. Commit
52900d22288ed ("udp: elide zerocopy operation in hot path") introduced
extra_uref to pass the initial reference taken in sock_zerocopy_alloc
to the first generated skb.
But, sock_zerocopy_realloc takes this extra reference at the start of
every call. With MSG_MORE, no new skb may be generated to attach the
extra_uref to, so refcnt is incorrectly 2 with only one skb.
Do not take the extra ref if uarg && !tcp, which implies MSG_MORE.
Update extra_uref accordingly.
This conditional assignment triggers a false positive may be used
uninitialized warning, so have to initialize extra_uref at define.
Changes v1->v2: fix typo in Fixes SHA1
Fixes:
52900d22288e7 ("udp: elide zerocopy operation in hot path")
Reported-by: syzbot <syzkaller@googlegroups.com>
Diagnosed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Maxime Chevallier [Thu, 30 May 2019 14:08:40 +0000 (16:08 +0200)]
ethtool: Check for vlan etype or vlan tci when parsing flow_rule
When parsing an ethtool flow spec to build a flow_rule, the code checks
if both the vlan etype and the vlan tci are specified by the user to add
a FLOW_DISSECTOR_KEY_VLAN match.
However, when the user only specified a vlan etype or a vlan tci, this
check silently ignores these parameters.
For example, the following rule :
ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0
will result in no error being issued, but the equivalent rule will be
created and passed to the NIC driver :
ethtool -N eth0 flow-type udp4 action -1 loc 0
In the end, neither the NIC driver using the rule nor the end user have
a way to know that these keys were dropped along the way, or that
incorrect parameters were entered.
This kind of check should be left to either the driver, or the ethtool
flow spec layer.
This commit makes so that ethtool parameters are forwarded as-is to the
NIC driver.
Since none of the users of ethtool_rx_flow_rule_create are using the
VLAN dissector, I don't think this qualifies as a regression.
Fixes:
eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Acked-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Wed, 29 May 2019 23:33:23 +0000 (16:33 -0700)]
net: don't clear sock->sk early to avoid trouble in strparser
af_inet sets sock->sk to NULL which trips strparser over:
BUG: kernel NULL pointer dereference, address:
0000000000000012
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 0 Comm: swapper/7 Not tainted
5.2.0-rc1-00139-g14629453a6d3 #21
RIP: 0010:tcp_peek_len+0x10/0x60
RSP: 0018:
ffffc02e41c54b98 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff9cf924c4e030 RCX:
0000000000000051
RDX:
0000000000000000 RSI:
000000000000000c RDI:
ffff9cf97128f480
RBP:
ffff9cf9365e0300 R08:
ffff9cf94fe7d2c0 R09:
0000000000000000
R10:
000000000000036b R11:
ffff9cf939735e00 R12:
ffff9cf91ad9ae40
R13:
ffff9cf924c4e000 R14:
ffff9cf9a8fcbaae R15:
0000000000000020
FS:
0000000000000000(0000) GS:
ffff9cf9af7c0000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000012 CR3:
000000013920a003 CR4:
00000000003606e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
<IRQ>
strp_data_ready+0x48/0x90
tls_data_ready+0x22/0xd0 [tls]
tcp_rcv_established+0x569/0x620
tcp_v4_do_rcv+0x127/0x1e0
tcp_v4_rcv+0xad7/0xbf0
ip_protocol_deliver_rcu+0x2c/0x1c0
ip_local_deliver_finish+0x41/0x50
ip_local_deliver+0x6b/0xe0
? ip_protocol_deliver_rcu+0x1c0/0x1c0
ip_rcv+0x52/0xd0
? ip_rcv_finish_core.isra.20+0x380/0x380
__netif_receive_skb_one_core+0x7e/0x90
netif_receive_skb_internal+0x42/0xf0
napi_gro_receive+0xed/0x150
nfp_net_poll+0x7a2/0xd30 [nfp]
? kmem_cache_free_bulk+0x286/0x310
net_rx_action+0x149/0x3b0
__do_softirq+0xe3/0x30a
? handle_irq_event_percpu+0x6a/0x80
irq_exit+0xe8/0xf0
do_IRQ+0x85/0xd0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0010:cpuidle_enter_state+0xbc/0x450
To avoid this issue set sock->sk after sk_prot->close.
My grepping and testing did not discover any code which
would depend on the current behaviour.
Fixes:
c46234ebb4d1 ("tls: RX path for ktls")
Reported-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 29 May 2019 22:36:10 +0000 (15:36 -0700)]
net-gro: fix use-after-free read in napi_gro_frags()
If a network driver provides to napi_gro_frags() an
skb with a page fragment of exactly 14 bytes, the call
to gro_pull_from_frag0() will 'consume' the fragment
by calling skb_frag_unref(skb, 0), and the page might
be freed and reused.
Reading eth->h_proto at the end of napi_frags_skb() might
read mangled data, or crash under specific debugging features.
BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline]
BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
Read of size 2 at addr
ffff88809366840c by task syz-executor599/8957
CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32
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+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
__kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
kasan_report+0x12/0x20 mm/kasan/common.c:614
__asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
napi_frags_skb net/core/dev.c:5833 [inline]
napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991
tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
call_write_iter include/linux/fs.h:1872 [inline]
do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
do_iter_write fs/read_write.c:970 [inline]
do_iter_write+0x184/0x610 fs/read_write.c:951
vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
do_writev+0x15b/0x330 fs/read_write.c:1058
Fixes:
a50e233c50db ("net-gro: restore frag0 optimization")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 30 May 2019 21:47:14 +0000 (14:47 -0700)]
Merge branch 'Fixes-for-DSA-tagging-using-802-1Q'
Vladimir Oltean says:
====================
Fixes for DSA tagging using 802.1Q
During the prototyping for the "Decoupling PHYLINK from struct
net_device" patchset, the CPU port of the sja1105 driver was moved to a
different spot. This uncovered an issue in the tag_8021q DSA code,
which used to work by mistake - the CPU port was the last hardware port
numerically, and this was masking an ordering issue which is very likely
to be seen in other drivers that make use of 802.1Q tags.
A question was also raised whether the VID numbers bear any meaning, and
the conclusion was that they don't, at least not in an absolute sense.
The second patch defines bit fields inside the DSA 802.1Q VID so that
tcpdump can decode it unambiguously (although the meaning is now clear
even by visual inspection).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Wed, 29 May 2019 21:42:31 +0000 (00:42 +0300)]
net: dsa: tag_8021q: Create a stable binary format
Tools like tcpdump need to be able to decode the significance of fake
VLAN headers that DSA uses to separate switch ports.
But currently these have no global significance - they are simply an
ordered list of DSA_MAX_SWITCHES x DSA_MAX_PORTS numbers ending at 4095.
The reason why this is submitted as a fix is that the existing mapping
of VIDs should not enter into a stable kernel, so we can pretend that
only the new format exists. This way tcpdump won't need to try to make
something out of the VLAN tags on 5.2 kernels.
Fixes:
f9bbe4477c30 ("net: dsa: Optional VLAN-based port separation for switches without tagging")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ioana Ciornei [Wed, 29 May 2019 21:42:30 +0000 (00:42 +0300)]
net: dsa: tag_8021q: Change order of rx_vid setup
The 802.1Q tagging performs an unbalanced setup in terms of RX VIDs on
the CPU port. For the ingress path of a 802.1Q switch to work, the RX
VID of a port needs to be seen as tagged egress on the CPU port.
While configuring the other front-panel ports to be part of this VID,
for bridge scenarios, the untagged flag is applied even on the CPU port
in dsa_switch_vlan_add. This happens because DSA applies the same flags
on the CPU port as on the (bridge-controlled) slave ports, and the
effect in this case is that the CPU port tagged settings get deleted.
Instead of fixing DSA by introducing a way to control VLAN flags on the
CPU port (and hence stop inheriting from the slave ports) - a hard,
perhaps intractable problem - avoid this situation by moving the setup
part of the RX VID on the CPU port after all the other front-panel ports
have been added to the VID.
Fixes:
f9bbe4477c30 ("net: dsa: Optional VLAN-based port separation for switches without tagging")
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Antoine Tenart [Wed, 29 May 2019 13:59:48 +0000 (15:59 +0200)]
net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value
MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but
the current code is passing the global tx queue offset, so it ends
up writing to unknown registers (between 0x8280 and 0x82fc, which
seemed to be unused by the hardware). This fixes the issue by using
the logical queue id instead.
Fixes:
3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Young Xiao [Wed, 29 May 2019 08:10:59 +0000 (16:10 +0800)]
ipv4: tcp_input: fix stack out of bounds when parsing TCP options.
The TCP option parsing routines in tcp_parse_options function could
read one byte out of the buffer of the TCP options.
1 while (length > 0) {
2 int opcode = *ptr++;
3 int opsize;
4
5 switch (opcode) {
6 case TCPOPT_EOL:
7 return;
8 case TCPOPT_NOP: /* Ref: RFC 793 section 3.1 */
9 length--;
10 continue;
11 default:
12 opsize = *ptr++; //out of bound access
If length = 1, then there is an access in line2.
And another access is occurred in line 12.
This would lead to out-of-bound access.
Therefore, in the patch we check that the available data length is
larger enough to pase both TCP option code and size.
Signed-off-by: Young Xiao <92siuyang@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 30 May 2019 19:30:47 +0000 (12:30 -0700)]
Merge branch 'mlxsw-Two-small-fixes'
Ido Schimmel says:
====================
mlxsw: Two small fixes
Patch #1 from Jiri fixes an issue specific to Spectrum-2 where the
insertion of two identical flower filters with different priorities
would trigger a warning.
Patch #2 from Amit prevents the driver from trying to configure a port
with a speed of 56Gb/s and autoneg off as this is not supported and
results in error messages from firmware.
Please consider patch #1 for stable.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Amit Cohen [Wed, 29 May 2019 07:59:45 +0000 (10:59 +0300)]
mlxsw: spectrum: Prevent force of 56G
Force of 56G is not supported by hardware in Ethernet devices. This
configuration fails with a bad parameter error from firmware.
Add check of this case. Instead of trying to set 56G with autoneg off,
return a meaningful error.
Fixes:
56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Pirko [Wed, 29 May 2019 07:59:44 +0000 (10:59 +0300)]
mlxsw: spectrum_acl: Avoid warning after identical rules insertion
When identical rules are inserted, the latter one goes to C-TCAM. For
that, a second eRP with the same mask is created. These 2 eRPs by the
nature cannot be merged and also one cannot be parent of another.
Teach mlxsw_sp_acl_erp_delta_fill() about this possibility and handle it
gracefully.
Reported-by: Alex Kushnarov <alexanderk@mellanox.com>
Fixes:
c22291f7cf45 ("mlxsw: spectrum: acl: Implement delta for ERP")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Rasmus Villemoes [Wed, 29 May 2019 07:02:11 +0000 (07:02 +0000)]
net: dsa: mv88e6xxx: fix handling of upper half of STATS_TYPE_PORT
Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends
up in bits 47:32 of the return value, instead of bits 31:16 as they
should.
Fixes:
6e46e2d821bb ("net: dsa: mv88e6xxx: Fix u64 statistics")
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Heiner Kallweit [Wed, 29 May 2019 05:44:01 +0000 (07:44 +0200)]
r8169: fix MAC address being lost in PCI D3
(At least) RTL8168e forgets its MAC address in PCI D3. To fix this set
the MAC address when resuming. For resuming from runtime-suspend we
had this in place already, for resuming from S3/S5 it was missing.
The commit referenced as being fixed isn't wrong, it's just the first
one where the patch applies cleanly.
Fixes:
0f07bd850d36 ("r8169: use dev_get_drvdata where possible")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reported-by: Albert Astals Cid <aacid@kde.org>
Tested-by: Albert Astals Cid <aacid@kde.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 30 May 2019 18:34:38 +0000 (11:34 -0700)]
Merge tag 'mlx5-fixes-2019-05-28' of git://git./linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
Mellanox, mlx5 fixes 2019-05-28
This series introduces some fixes to mlx5 driver.
Please pull and let me know if there is any problem.
For -stable v4.13:
('net/mlx5: Allocate root ns memory using kzalloc to match kfree')
For -stable v4.16:
('net/mlx5: Avoid double free in fs init error unwinding path')
For -stable v4.18:
('net/mlx5e: Disable rxhash when CQE compress is enabled')
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 30 May 2019 18:12:21 +0000 (11:12 -0700)]
Merge branch 'XDP-generic-fixes'
Stephen Hemminger says:
====================
XDP generic fixes
This set of patches came about while investigating XDP
generic on Azure. The split brain nature of the accelerated
networking exposed issues with the stack device model.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Stephen Hemminger [Tue, 28 May 2019 18:47:31 +0000 (11:47 -0700)]
net: core: support XDP generic on stacked devices.
When a device is stacked like (team, bonding, failsafe or netvsc) the
XDP generic program for the parent device was not called.
Move the call to XDP generic inside __netif_receive_skb_core where
it can be done multiple times for stacked case.
Fixes:
d445516966dc ("net: xdp: support xdp generic on virtual devices")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stephen Hemminger [Tue, 28 May 2019 18:47:30 +0000 (11:47 -0700)]
netvsc: unshare skb in VF rx handler
The netvsc VF skb handler should make sure that skb is not
shared. Similar logic already exists in bonding and team device
drivers.
This is not an issue in practice because the VF devicex
does not send up shared skb's. But the netvsc driver
should do the right thing if it did.
Fixes:
0c195567a8f6 ("netvsc: transparent VF management")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sean Tranchetti [Tue, 28 May 2019 18:22:54 +0000 (12:22 -0600)]
udp: Avoid post-GRO UDP checksum recalculation
Currently, when resegmenting an unexpected UDP GRO packet, the full UDP
checksum will be calculated for every new SKB created by skb_segment()
because the netdev features passed in by udp_rcv_segment() lack any
information about checksum offload capabilities.
Usually, we have no need to perform this calculation again, as
1) The GRO implementation guarantees that any packets making it to the
udp_rcv_segment() function had correct checksums, and, more
importantly,
2) Upon the successful return of udp_rcv_segment(), we immediately pull
the UDP header off and either queue the segment to the socket or
hand it off to a new protocol handler.
Unless userspace has set the IP_CHECKSUM sockopt to indicate that they
want the final checksum values, we can pass the needed netdev feature
flags to __skb_gso_segment() to avoid checksumming each segment in
skb_segment().
Fixes:
cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Airlie [Thu, 30 May 2019 00:58:17 +0000 (10:58 +1000)]
Merge branch 'drm-fixes-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
- Respin the Raven DMCU patch with the ifdef fixed
- Fix for a clean display when loading the driver on Raven
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190529170347.3272-1-alexander.deucher@amd.com
Dave Airlie [Thu, 30 May 2019 00:51:07 +0000 (10:51 +1000)]
Merge tag 'drm-misc-fixes-2019-05-29' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
qxl: Drop WARN when u/s tries to mmap a prime buffer (Gerd)
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20190529211833.GA195708@art_vandelay
Dave Airlie [Thu, 30 May 2019 00:48:09 +0000 (10:48 +1000)]
Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes
etnaviv core dump locking fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1558966666.4039.4.camel@pengutronix.de
Linus Torvalds [Wed, 29 May 2019 21:36:41 +0000 (14:36 -0700)]
Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/linux
Pull documentation fixes from Jonathan Corbet:
"The Sphinx 2.0 release contained a few incompatible API changes that
broke our extensions and, thus, the documentation build in general.
Who knew that those deprecation warnings it was outputting actually
meant we should change something? This set of fixes makes the build
work again with Sphinx 2.0 and eliminates the warnings for 1.8. As
part of that, we also need a few fixes to the docs for places where
the new Sphinx is more strict.
It is a bit late in the cycle for this kind of change, but it does fix
problems that people are experiencing now.
There has been some talk of raising the minimum version of Sphinx we
support. I don't want to do that abruptly, though, so these changes
add some glue to continue to support versions back to 1.3. We will be
adding some infrastructure soon to nudge users of old versions
forward, with the idea of maybe increasing our minimum version (and
removing this glue) sometime in the future"
* tag 'docs-5.2-fixes2' of git://git.lwn.net/linux:
drm/i915: Maintain consistent documentation subsection ordering
scripts/sphinx-pre-install: make it handle Sphinx versions
docs: Fix conf.py for Sphinx 2.0
docs: fix multiple doc build warnings in enumeration.rst
lib/list_sort: fix kerneldoc build error
docs: fix numaperf.rst and add it to the doc tree
doc: Cope with the deprecation of AutoReporter
doc: Cope with Sphinx logging deprecations
David S. Miller [Wed, 29 May 2019 21:28:48 +0000 (14:28 -0700)]
Merge branch 'net-phy-dp83867-add-some-fixes'
Max Uvarov says:
====================
net: phy: dp83867: add some fixes
v3: use phy_modify_mmd()
v2: fix minor comments by Heiner Kallweit and Florian Fainelli
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Max Uvarov [Tue, 28 May 2019 10:00:52 +0000 (13:00 +0300)]
net: phy: dp83867: Set up RGMII TX delay
PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
so code to set tx delay is never called.
Fixes:
2a10154abcb75 ("net: phy: dp83867: Add TI dp83867 phy")
Signed-off-by: Max Uvarov <muvarov@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Max Uvarov [Tue, 28 May 2019 10:00:51 +0000 (13:00 +0300)]
net: phy: dp83867: do not call config_init twice
Phy state machine calls _config_init just after
reset.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Max Uvarov [Tue, 28 May 2019 10:00:50 +0000 (13:00 +0300)]
net: phy: dp83867: increase SGMII autoneg timer duration
After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01).
That is not enough to finalize autonegatiation on some devices.
Increase this timer duration to maximum supported 16ms.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Max Uvarov [Tue, 28 May 2019 10:00:49 +0000 (13:00 +0300)]
net: phy: dp83867: fix speed 10 in sgmii mode
For supporting 10Mps speed in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit
of DP83867_10M_SGMII_CFG register has to be cleared by software.
That does not affect speeds 100 and 1000 so can be done on init.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Tue, 28 May 2019 09:34:42 +0000 (10:34 +0100)]
net: phy: marvell10g: report if the PHY fails to boot firmware
Some boards do not have the PHY firmware programmed in the 3310's flash,
which leads to the PHY not working as expected. Warn the user when the
PHY fails to boot the firmware and refuse to initialise.
Fixes:
20b2af32ff3f ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Tue, 28 May 2019 09:27:21 +0000 (10:27 +0100)]
net: phylink: ensure consistent phy interface mode
Ensure that we supply the same phy interface mode to mac_link_down() as
we did for the corresponding mac_link_up() call. This ensures that MAC
drivers that use the phy interface mode in these methods can depend on
mac_link_down() always corresponding to a mac_link_up() call for the
same interface mode.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shuah Khan [Wed, 29 May 2019 19:46:15 +0000 (13:46 -0600)]
usbip: usbip_host: fix stub_dev lock context imbalance regression
Fix the following sparse context imbalance regression introduced in
a patch that fixed sleeping function called from invalid context bug.
kbuild test robot reported on:
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus
Regressions in current branch:
drivers/usb/usbip/stub_dev.c:399:9: sparse: sparse: context imbalance in 'stub_probe' - different lock contexts for basic block
drivers/usb/usbip/stub_dev.c:418:13: sparse: sparse: context imbalance in 'stub_disconnect' - different lock contexts for basic block
drivers/usb/usbip/stub_dev.c:464:1-10: second lock on line 476
Error ids grouped by kconfigs:
recent_errors
├── i386-allmodconfig
│ └── drivers-usb-usbip-stub_dev.c:second-lock-on-line
├── x86_64-allmodconfig
│ ├── drivers-usb-usbip-stub_dev.c:sparse:sparse:context-imbalance-in-stub_disconnect-different-lock-contexts-for-basic-block
│ └── drivers-usb-usbip-stub_dev.c:sparse:sparse:context-imbalance-in-stub_probe-different-lock-contexts-for-basic-block
└── x86_64-allyesconfig
└── drivers-usb-usbip-stub_dev.c:second-lock-on-line
This is a real problem in an error leg where spin_lock() is called on an
already held lock.
Fix the imbalance in stub_probe() and stub_disconnect().
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Fixes:
0c9e8b3cad65 ("usbip: usbip_host: fix BUG: sleeping function called from invalid context")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Tue, 28 May 2019 04:10:46 +0000 (13:10 +0900)]
net: sh_eth: fix mdio access in sh_eth_close() for R-Car Gen2 and RZ/A1 SoCs
The sh_eth_close() resets the MAC and then calls phy_stop()
so that mdio read access result is incorrect without any error
according to kernel trace like below:
ifconfig-216 [003] .n.. 109.133124: mdio_access:
ee700000.ethernet-
ffffffff read phy:0x01 reg:0x00 val:0xffff
According to the hardware manual, the RMII mode should be set to 1
before operation the Ethernet MAC. However, the previous code was not
set to 1 after the driver issued the soft_reset in sh_eth_dev_exit()
so that the mdio read access result seemed incorrect. To fix the issue,
this patch adds a condition and set the RMII mode register in
sh_eth_dev_exit() for R-Car Gen2 and RZ/A1 SoCs.
Note that when I have tried to move the sh_eth_dev_exit() calling
after phy_stop() on sh_eth_close(), but it gets worse (kernel panic
happened and it seems that a register is accessed while the clock is
off).
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Wed, 29 May 2019 20:20:02 +0000 (13:20 -0700)]
Merge tag 'linux-kselftest-5.2-rc3' of git://git./linux/kernel/git/shuah/linux-kselftest
Pull Kselftest fixes from Shuah Khan:
- Alexandre Belloni's fixes to rtc regressions introduced in kselftest
Makefile test run output refactoring work from Kees Cook.
- ftrace test checkbashisms fixes from Masami Hiramatsu
* tag 'linux-kselftest-5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests: rtc: rtctest: specify timeouts
selftests/harness: Allow test to configure timeout
selftests/ftrace: Add checkbashisms meta-testcase
selftests/ftrace: Make a script checkbashisms clean
Linus Torvalds [Wed, 29 May 2019 18:26:40 +0000 (11:26 -0700)]
Merge tag 'trace-v5.2-rc2' of git://git./linux/kernel/git/rostedt/linux-trace
Pull tracing fix from Steven Rostedt:
"This fixes a memory leak from the error path in the event filter
logic"
* tag 'trace-v5.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Avoid memory leak in predicate_parse()
Flora Cui [Tue, 28 May 2019 07:52:42 +0000 (15:52 +0800)]
drm/amdgpu: reserve stollen vram for raven series
to avoid screen corruption during modprobe.
Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sami Tolvanen [Fri, 24 May 2019 22:11:18 +0000 (15:11 -0700)]
arm64: use the correct function type for __arm64_sys_ni_syscall
Calling sys_ni_syscall through a syscall_fn_t pointer trips indirect
call Control-Flow Integrity checking due to a function type
mismatch. Use SYSCALL_DEFINE0 for __arm64_sys_ni_syscall instead and
remove the now unnecessary casts.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Sami Tolvanen [Fri, 24 May 2019 22:11:17 +0000 (15:11 -0700)]
arm64: use the correct function type in SYSCALL_DEFINE0
Although a syscall defined using SYSCALL_DEFINE0 doesn't accept
parameters, use the correct function type to avoid indirect call
type mismatches with Control-Flow Integrity checking.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Sami Tolvanen [Fri, 24 May 2019 22:11:16 +0000 (15:11 -0700)]
arm64: fix syscall_fn_t type
Syscall wrappers in <asm/syscall_wrapper.h> use const struct pt_regs *
as the argument type. Use const in syscall_fn_t as well to fix indirect
call type mismatches with Control-Flow Integrity checking.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Geert Uytterhoeven [Tue, 28 May 2019 14:24:23 +0000 (16:24 +0200)]
ALSA: fireface: Use ULL suffixes for 64-bit constants
With gcc 4.1:
sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_switch_fetching_mode’:
sound/firewire/fireface/ff-protocol-latter.c:97: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_begin_session’:
sound/firewire/fireface/ff-protocol-latter.c:170: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c:197: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c:205: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_finish_session’:
sound/firewire/fireface/ff-protocol-latter.c:214: warning: integer constant is too large for ‘long’ type
Fix this by adding the missing "ULL" suffixes.
Add the same suffix to the last constant, to maintain consistency.
Fixes:
fd1cc9de64c2ca6c ("ALSA: fireface: add support for Fireface UCX")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Eric W. Biederman [Thu, 23 May 2019 16:11:19 +0000 (11:11 -0500)]
signal/arm64: Use force_sig not force_sig_fault for SIGKILL
I don't think this is userspace visible but SIGKILL does not have
any si_codes that use the fault member of the siginfo union. Correct
this the simple way and call force_sig instead of force_sig_fault when
the signal is SIGKILL.
The two know places where synchronous SIGKILL are generated are
do_bad_area and fpsimd_save. The call paths to force_sig_fault are:
do_bad_area
arm64_force_sig_fault
force_sig_fault
force_signal_inject
arm64_notify_die
arm64_force_sig_fault
force_sig_fault
Which means correcting this in arm64_force_sig_fault is enough
to ensure the arm64 code is not misusing the generic code, which
could lead to maintenance problems later.
Cc: stable@vger.kernel.org
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Fixes:
af40ff687bc9 ("arm64: signal: Ensure si_code is valid for all fault signals")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Hui Wang [Wed, 29 May 2019 04:41:38 +0000 (12:41 +0800)]
ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops
We met another Acer Aspire laptop which has the problem on the
headset-mic, the Pin 0x19 is not set the corret configuration for a
mic and the pin presence can't be detected too after plugging a
headset. Kailang suggested that we should set the coeff to enable the
mic and apply the ALC269_FIXUP_LIFEBOOK_EXTMIC. After doing that,
both headset-mic presence and headset-mic work well.
The existing ALC255_FIXUP_ACER_MIC_NO_PRESENCE set the headset-mic
jack to be a phantom jack. Now since the jack can support presence
unsol event, let us imporve it to set the jack to be a normal jack.
https://bugs.launchpad.net/bugs/
1821269
Fixes:
5824ce8de7b1c ("ALSA: hda/realtek - Add support for Acer Aspire E5-475 headset mic")
Cc: Chris Chiu <chiu@endlessm.com>
CC: Daniel Drake <drake@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Saeed Mahameed [Thu, 23 May 2019 19:55:10 +0000 (12:55 -0700)]
net/mlx5e: Disable rxhash when CQE compress is enabled
When CQE compression is enabled (Multi-host systems), compressed CQEs
might arrive to the driver rx, compressed CQEs don't have a valid hash
offload and the driver already reports a hash value of 0 and invalid hash
type on the skb for compressed CQEs, but this is not good enough.
On a congested PCIe, where CQE compression will kick in aggressively,
gro will deliver lots of out of order packets due to the invalid hash
and this might cause a serious performance drop.
The only valid solution, is to disable rxhash offload at all when CQE
compression is favorable (Multi-host systems).
Fixes:
7219ab34f184 ("net/mlx5e: CQE compression")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
wenxu [Wed, 15 May 2019 09:25:45 +0000 (17:25 +0800)]
net/mlx5e: restrict the real_dev of vlan device is the same as uplink device
When register indr block for vlan device, it should check the real_dev
of vlan device is same as uplink device. Or it will set offload rule
to mlx5e which will never hit.
Fixes:
35a605db168c ("net/mlx5e: Offload TC e-switch rules with ingress VLAN device")
Signed-off-by: wenxu <wenxu@ucloud.cn>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Parav Pandit [Fri, 10 May 2019 15:40:08 +0000 (10:40 -0500)]
net/mlx5: Allocate root ns memory using kzalloc to match kfree
root ns is yet another fs core node which is freed using kfree() by
tree_put_node().
Rest of the other fs core objects are also allocated using kmalloc
variants.
However, root ns memory is allocated using kvzalloc().
Hence allocate root ns memory using kzalloc().
Fixes:
2530236303d9e ("net/mlx5_core: Flow steering tree initialization")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Parav Pandit [Fri, 10 May 2019 15:26:23 +0000 (10:26 -0500)]
net/mlx5: Avoid double free in fs init error unwinding path
In below code flow, for ingress acl table root ns memory leads
to double free.
mlx5_init_fs
init_ingress_acls_root_ns()
init_ingress_acl_root_ns
kfree(steering->esw_ingress_root_ns);
/* steering->esw_ingress_root_ns is not marked NULL */
mlx5_cleanup_fs
cleanup_ingress_acls_root_ns
steering->esw_ingress_root_ns non NULL check passes.
kfree(steering->esw_ingress_root_ns);
/* double free */
Similar issue exist for other tables.
Hence zero out the pointers to not process the table again.
Fixes:
9b93ab981e3bf ("net/mlx5: Separate ingress/egress namespaces for each vport")
Fixes:
40c3eebb49e51 ("net/mlx5: Add support in RDMA RX steering")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Parav Pandit [Thu, 9 May 2019 22:23:24 +0000 (17:23 -0500)]
net/mlx5: Avoid double free of root ns in the error flow path
When root ns setup for rdma, sniffer tx and sniffer rx fails,
such root ns cleanup is done by the error unwinding path of
mlx5_cleanup_fs().
Below call graph shows an example for sniffer_rx_root_ns.
mlx5_init_fs()
init_sniffer_rx_root_ns()
cleanup_root_ns(steering->sniffer_rx_root_ns);
mlx5_cleanup_fs()
cleanup_root_ns(steering->sniffer_rx_root_ns);
/* double free of sniffer_rx_root_ns */
Hence, use the existing cleanup_fs to cleanup.
Fixes:
d83eb50e29de3 ("net/mlx5: Add support in RDMA RX steering")
Fixes:
87d22483ce68e ("net/mlx5: Add sniffer namespaces")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Saeed Mahameed [Thu, 16 May 2019 18:11:11 +0000 (11:11 -0700)]
net/mlx5: Fix error handling in mlx5_load()
In case mlx5_core_set_hca_defaults fails, it should jump to
mlx5_cleanup_fs, fix that.
Fixes:
c85023e153e3 ("IB/mlx5: Add raw ethernet local loopback support")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Huy Nguyen <huyn@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Florian Fainelli [Tue, 28 May 2019 02:06:38 +0000 (19:06 -0700)]
Documentation: net-sysfs: Remove duplicate PHY device documentation
Both sysfs-bus-mdio and sysfs-class-net-phydev contain the same
duplication information. There is not currently any MDIO bus specific
attribute, but there are PHY device (struct phy_device) specific
attributes. Use the more precise description from sysfs-bus-mdio and
carry that over to sysfs-class-net-phydev.
Fixes:
86f22d04dfb5 ("net: sysfs: Document PHY device sysfs attributes")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 28 May 2019 00:35:52 +0000 (17:35 -0700)]
llc: fix skb leak in llc_build_and_send_ui_pkt()
If llc_mac_hdr_init() returns an error, we must drop the skb
since no llc_build_and_send_ui_pkt() caller will take care of this.
BUG: memory leak
unreferenced object 0xffff8881202b6800 (size 2048):
comm "syz-executor907", pid 7074, jiffies
4294943781 (age 8.590s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<
00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[<
00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<
00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline]
[<
00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline]
[<
00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
[<
00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline]
[<
00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608
[<
00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662
[<
000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<
00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
[<
0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430
[<
000000008bdec225>] sock_create net/socket.c:1481 [inline]
[<
000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523
[<
00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline]
[<
00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline]
[<
00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530
[<
00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<
000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88811d750d00 (size 224):
comm "syz-executor907", pid 7074, jiffies
4294943781 (age 8.600s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff ...$.....h+ ....
backtrace:
[<
0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[<
0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<
0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline]
[<
0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<
00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
[<
00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline]
[<
00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
[<
000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
[<
00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
[<
00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<
00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<
00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<
000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
[<
00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline]
[<
00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline]
[<
00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
[<
00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<
000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stefano Brivio [Mon, 27 May 2019 17:42:23 +0000 (19:42 +0200)]
selftests: pmtu: Fix encapsulating device in pmtu_vti6_link_change_mtu
In the pmtu_vti6_link_change_mtu test, both local and remote addresses
for the vti6 tunnel are assigned to the same address given to the dummy
interface that we use as encapsulating device with a known MTU.
This works as long as the dummy interface is actually selected, via
rt6_lookup(), as encapsulating device. But if the remote address of the
tunnel is a local address too, the loopback interface could also be
selected, and there's nothing wrong with it.
This is what some older -stable kernels do (3.18.z, at least), and
nothing prevents us from subtly changing FIB implementation to revert
back to that behaviour in the future.
Define an IPv6 prefix instead, and use two separate addresses as local
and remote for vti6, so that the encapsulating device can't be a
loopback interface.
Reported-by: Xiumei Mu <xmu@redhat.com>
Fixes:
1fad59ea1c34 ("selftests: pmtu: Add pmtu_vti6_link_change_mtu test")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tomas Bortoli [Tue, 28 May 2019 15:43:38 +0000 (17:43 +0200)]
tracing: Avoid memory leak in predicate_parse()
In case of errors, predicate_parse() goes to the out_free label
to free memory and to return an error code.
However, predicate_parse() does not free the predicates of the
temporary prog_stack array, thence leaking them.
Link: http://lkml.kernel.org/r/20190528154338.29976-1-tomasbortoli@gmail.com
Cc: stable@vger.kernel.org
Fixes:
80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster")
Reported-by: syzbot+6b8e0fb820e570c59e19@syzkaller.appspotmail.com
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
[ Added protection around freeing prog_stack[i].pred ]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Madalin Bucur [Mon, 27 May 2019 12:24:05 +0000 (15:24 +0300)]
dpaa_eth: use only online CPU portals
Make sure only the portals for the online CPUs are used.
Without this change, there are issues when someone boots with
maxcpus=n, with n < actual number of cores available as frames
either received or corresponding to the transmit confirmation
path would be offered for dequeue to the offline CPU portals,
getting lost.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jisheng Zhang [Mon, 27 May 2019 11:04:17 +0000 (11:04 +0000)]
net: mvneta: Fix err code path of probe
Fix below issues in err code path of probe:
1. we don't need to unregister_netdev() because the netdev isn't
registered.
2. when register_netdev() fails, we also need to destroy bm pool for
HWBM case.
Fixes:
dc35a10f68d3 ("net: mvneta: bm: add support for hardware buffer management")
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thierry Reding [Mon, 27 May 2019 10:52:51 +0000 (12:52 +0200)]
net: stmmac: Do not output error on deferred probe
If the subdriver defers probe, do not show an error message. It's
perfectly fine for this error to occur since the driver will get another
chance to probe after some time and will usually succeed after all of
the resources that it requires have been registered.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Filipe Manana [Wed, 15 May 2019 15:03:17 +0000 (16:03 +0100)]
Btrfs: fix race updating log root item during fsync
When syncing the log, the final phase of a fsync operation, we need to
either create a log root's item or update the existing item in the log
tree of log roots, and that depends on the current value of the log
root's log_transid - if it's 1 we need to create the log root item,
otherwise it must exist already and we update it. Since there is no
synchronization between updating the log_transid and checking it for
deciding whether the log root's item needs to be created or updated, we
end up with a tiny race window that results in attempts to update the
item to fail because the item was not yet created:
CPU 1 CPU 2
btrfs_sync_log()
lock root->log_mutex
set log root's log_transid to 1
unlock root->log_mutex
btrfs_sync_log()
lock root->log_mutex
sets log root's
log_transid to 2
unlock root->log_mutex
update_log_root()
sees log root's log_transid
with a value of 2
calls btrfs_update_root(),
which fails with -EUCLEAN
and causes transaction abort
Until recently the race lead to a BUG_ON at btrfs_update_root(), but after
the recent commit
7ac1e464c4d47 ("btrfs: Don't panic when we can't find a
root key") we just abort the current transaction.
A sample trace of the BUG_ON() on a SLE12 kernel:
------------[ cut here ]------------
kernel BUG at ../fs/btrfs/root-tree.c:157!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=2048 NUMA pSeries
(...)
Supported: Yes, External
CPU: 78 PID: 76303 Comm: rtas_errd Tainted: G X 4.4.156-94.57-default #1
task:
c00000ffa906d010 ti:
c00000ff42b08000 task.ti:
c00000ff42b08000
NIP:
d000000036ae5cdc LR:
d000000036ae5cd8 CTR:
0000000000000000
REGS:
c00000ff42b0b860 TRAP: 0700 Tainted: G X (4.4.156-94.57-default)
MSR:
8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR:
22444484 XER:
20000000
CFAR:
d000000036aba66c SOFTE: 1
GPR00:
d000000036ae5cd8 c00000ff42b0bae0 d000000036bda220 0000000000000054
GPR04:
0000000000000001 0000000000000000 c00007ffff8d37c8 0000000000000000
GPR08:
c000000000e19c00 0000000000000000 0000000000000000 3736343438312079
GPR12:
3930373337303434 c000000007a3a800 00000000007fffff 0000000000000023
GPR16:
c00000ffa9d26028 c00000ffa9d261f8 0000000000000010 c00000ffa9d2ab28
GPR20:
c00000ff42b0bc48 0000000000000001 c00000ff9f0d9888 0000000000000001
GPR24:
c00000ffa9d26000 c00000ffa9d261e8 c00000ffa9d2a800 c00000ff9f0d9888
GPR28:
c00000ffa9d26028 c00000ffa9d2aa98 0000000000000001 c00000ffa98f5b20
NIP [
d000000036ae5cdc] btrfs_update_root+0x25c/0x4e0 [btrfs]
LR [
d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs]
Call Trace:
[
c00000ff42b0bae0] [
d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs] (unreliable)
[
c00000ff42b0bba0] [
d000000036b53610] btrfs_sync_log+0x2d0/0xc60 [btrfs]
[
c00000ff42b0bce0] [
d000000036b1785c] btrfs_sync_file+0x44c/0x4e0 [btrfs]
[
c00000ff42b0bd80] [
c00000000032e300] vfs_fsync_range+0x70/0x120
[
c00000ff42b0bdd0] [
c00000000032e44c] do_fsync+0x5c/0xb0
[
c00000ff42b0be10] [
c00000000032e8dc] SyS_fdatasync+0x2c/0x40
[
c00000ff42b0be30] [
c000000000009488] system_call+0x3c/0x100
Instruction dump:
7f43d378 4bffebb9 60000000 88d90008 3d220000 e8b90000 3b390009 e87a01f0
e8898e08 e8f90000 4bfd48e5 60000000 <
0fe00000>
e95b0060 39200004 394a0ea0
---[ end trace
8f2dc8f919cabab8 ]---
So fix this by doing the check of log_transid and updating or creating the
log root's item while holding the root's log_mutex.
Fixes:
7237f1833601d ("Btrfs: fix tree logs parallel sync")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Wed, 15 May 2019 15:02:47 +0000 (16:02 +0100)]
Btrfs: fix wrong ctime and mtime of a directory after log replay
When replaying a log that contains a new file or directory name that needs
to be added to its parent directory, we end up updating the mtime and the
ctime of the parent directory to the current time after we have set their
values to the correct ones (set at fsync time), efectivelly losing them.
Sample reproducer:
$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt
$ mkdir /mnt/dir
$ touch /mnt/dir/file
# fsync of the directory is optional, not needed
$ xfs_io -c fsync /mnt/dir
$ xfs_io -c fsync /mnt/dir/file
$ stat -c %Y /mnt/dir
1557856079
<power failure>
$ sleep 3
$ mount /dev/sdb /mnt
$ stat -c %Y /mnt/dir
1557856082
--> should have been
1557856079, the mtime is updated to the current
time when replaying the log
Fix this by not updating the mtime and ctime to the current time at
btrfs_add_link() when we are replaying a log tree.
This could be triggered by my recent fsync fuzz tester for fstests, for
which an fstests patch exists titled "fstests: generic, fsync fuzz tester
with fsstress".
Fixes:
e02119d5a7b43 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Thu, 16 May 2019 14:48:55 +0000 (15:48 +0100)]
Btrfs: fix fsync not persisting changed attributes of a directory
While logging an inode we follow its ancestors and for each one we mark
it as logged in the current transaction, even if we have not logged it.
As a consequence if we change an attribute of an ancestor, such as the
UID or GID for example, and then explicitly fsync it, we end up not
logging the inode at all despite returning success to user space, which
results in the attribute being lost if a power failure happens after
the fsync.
Sample reproducer:
$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt
$ mkdir /mnt/dir
$ chown 6007:6007 /mnt/dir
$ sync
$ chown 9003:9003 /mnt/dir
$ touch /mnt/dir/file
$ xfs_io -c fsync /mnt/dir/file
# fsync our directory after fsync'ing the new file, should persist the
# new values for the uid and gid.
$ xfs_io -c fsync /mnt/dir
<power failure>
$ mount /dev/sdb /mnt
$ stat -c %u:%g /mnt/dir
6007:6007
--> should be 9003:9003, the uid and gid were not persisted, despite
the explicit fsync on the directory prior to the power failure
Fix this by not updating the logged_trans field of ancestor inodes when
logging an inode, since we have not logged them. Let only future calls to
btrfs_log_inode() to mark inodes as logged.
This could be triggered by my recent fsync fuzz tester for fstests, for
which an fstests patch exists titled "fstests: generic, fsync fuzz tester
with fsstress".
Fixes:
12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Tue, 21 May 2019 11:28:08 +0000 (19:28 +0800)]
btrfs: qgroup: Check bg while resuming relocation to avoid NULL pointer dereference
[BUG]
When mounting a fs with reloc tree and has qgroup enabled, it can cause
NULL pointer dereference at mount time:
BUG: kernel NULL pointer dereference, address:
00000000000000a8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:btrfs_qgroup_add_swapped_blocks+0x186/0x300 [btrfs]
Call Trace:
replace_path.isra.23+0x685/0x900 [btrfs]
merge_reloc_root+0x26e/0x5f0 [btrfs]
merge_reloc_roots+0x10a/0x1a0 [btrfs]
btrfs_recover_relocation+0x3cd/0x420 [btrfs]
open_ctree+0x1bc8/0x1ed0 [btrfs]
btrfs_mount_root+0x544/0x680 [btrfs]
legacy_get_tree+0x34/0x60
vfs_get_tree+0x2d/0xf0
fc_mount+0x12/0x40
vfs_kern_mount.part.12+0x61/0xa0
vfs_kern_mount+0x13/0x20
btrfs_mount+0x16f/0x860 [btrfs]
legacy_get_tree+0x34/0x60
vfs_get_tree+0x2d/0xf0
do_mount+0x81f/0xac0
ksys_mount+0xbf/0xe0
__x64_sys_mount+0x25/0x30
do_syscall_64+0x65/0x240
entry_SYSCALL_64_after_hwframe+0x49/0xbe
[CAUSE]
In btrfs_recover_relocation(), we don't have enough info to determine
which block group we're relocating, but only to merge existing reloc
trees.
Thus in btrfs_recover_relocation(), rc->block_group is NULL.
btrfs_qgroup_add_swapped_blocks() hasn't taken this into consideration,
and causes a NULL pointer dereference.
The bug is introduced by commit
3d0174f78e72 ("btrfs: qgroup: Only trace
data extents in leaves if we're relocating data block group"), and
later qgroup refactoring still keeps this optimization.
[FIX]
Thankfully in the context of btrfs_recover_relocation(), there is no
other progress can modify tree blocks, thus those swapped tree blocks
pair will never affect qgroup numbers, no matter whatever we set for
block->trace_leaf.
So we only need to check if @bg is NULL before accessing @bg->flags.
Reported-by: Juan Erbes <jerbes@gmail.com>
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1134806
Fixes:
3d0174f78e72 ("btrfs: qgroup: Only trace data extents in leaves if we're relocating data block group")
CC: stable@vger.kernel.org # 4.20+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Qu Wenruo [Wed, 22 May 2019 08:33:11 +0000 (16:33 +0800)]
btrfs: reloc: Also queue orphan reloc tree for cleanup to avoid BUG_ON()
[BUG]
When a fs has orphan reloc tree along with unfinished balance:
...
item 16 key (TREE_RELOC ROOT_ITEM FS_TREE) itemoff 12090 itemsize 439
generation 12 root_dirid 256 bytenr
300400640 level 1 refs 0 <<<
lastsnap 8 byte_limit 0 bytes_used
1359872 flags 0x0(none)
uuid
7c48d938-33a3-4aae-ab19-
6e5c9d406e46
item 17 key (BALANCE TEMPORARY_ITEM 0) itemoff 11642 itemsize 448
temporary item objectid BALANCE offset 0
balance status flags 14
Then at mount time, we can hit the following kernel BUG_ON():
BTRFS info (device dm-3): relocating block group
298844160 flags metadata|dup
------------[ cut here ]------------
kernel BUG at fs/btrfs/relocation.c:1413!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 897 Comm: btrfs-balance Tainted: G O 5.2.0-rc1-custom #15
RIP: 0010:create_reloc_root+0x1eb/0x200 [btrfs]
Call Trace:
btrfs_init_reloc_root+0x96/0xb0 [btrfs]
record_root_in_trans+0xb2/0xe0 [btrfs]
btrfs_record_root_in_trans+0x55/0x70 [btrfs]
select_reloc_root+0x7e/0x230 [btrfs]
do_relocation+0xc4/0x620 [btrfs]
relocate_tree_blocks+0x592/0x6a0 [btrfs]
relocate_block_group+0x47b/0x5d0 [btrfs]
btrfs_relocate_block_group+0x183/0x2f0 [btrfs]
btrfs_relocate_chunk+0x4e/0xe0 [btrfs]
btrfs_balance+0x864/0xfa0 [btrfs]
balance_kthread+0x3b/0x50 [btrfs]
kthread+0x123/0x140
ret_from_fork+0x27/0x50
[CAUSE]
In btrfs, reloc trees are used to record swapped tree blocks during
balance.
Reloc tree either get merged (replace old tree blocks of its parent
subvolume) in next transaction if its ref is 1 (fresh).
Or is already merged and will be cleaned up if its ref is 0 (orphan).
After commit
d2311e698578 ("btrfs: relocation: Delay reloc tree deletion
after merge_reloc_roots"), reloc tree cleanup is delayed until one block
group is balanced.
Since fresh reloc roots are recorded during merge, as long as there
is no power loss, those orphan reloc roots converted from fresh ones are
handled without problem.
However when power loss happens, orphan reloc roots can be recorded
on-disk, thus at next mount time, we will have orphan reloc roots from
on-disk data directly, and ignored by clean_dirty_subvols() routine.
Then when background balance starts to balance another block group, and
needs to create new reloc root for the same root, btrfs_insert_item()
returns -EEXIST, and trigger that BUG_ON().
[FIX]
For orphan reloc roots, also queue them to rc->dirty_subvol_roots, so
all reloc roots no matter orphan or not, can be cleaned up properly and
avoid above BUG_ON().
And to cooperate with above change, clean_dirty_subvols() will check if
the queued root is a reloc root or a subvol root.
For a subvol root, do the old work, and for a orphan reloc root, clean it
up.
Fixes:
d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots")
CC: stable@vger.kernel.org # 5.1
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Mon, 20 May 2019 08:57:00 +0000 (09:57 +0100)]
Btrfs: incremental send, fix emission of invalid clone operations
When doing an incremental send we can now issue clone operations with a
source range that ends at the source's file eof and with a destination
range that ends at an offset smaller then the destination's file eof.
If the eof of the source file is not aligned to the sector size of the
filesystem, the receiver will get a -EINVAL error when trying to do the
operation or, on older kernels, silently corrupt the destination file.
The corruption happens on kernels without commit
ac765f83f1397646
("Btrfs: fix data corruption due to cloning of eof block"), while the
failure to clone happens on kernels with that commit.
Example reproducer:
$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt/sdb
$ xfs_io -f -c "pwrite -S 0xb1 0 2M" /mnt/sdb/foo
$ xfs_io -f -c "pwrite -S 0xc7 0 2M" /mnt/sdb/bar
$ xfs_io -f -c "pwrite -S 0x4d 0 2M" /mnt/sdb/baz
$ xfs_io -f -c "pwrite -S 0xe2 0 2M" /mnt/sdb/zoo
$ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/base
$ btrfs send -f /tmp/base.send /mnt/sdb/base
$ xfs_io -c "reflink /mnt/sdb/bar 1560K 500K 100K" /mnt/sdb/bar
$ xfs_io -c "reflink /mnt/sdb/bar 1560K 0 100K" /mnt/sdb/zoo
$ xfs_io -c "truncate 550K" /mnt/sdb/bar
$ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/incr
$ btrfs send -f /tmp/incr.send -p /mnt/sdb/base /mnt/sdb/incr
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt/sdc
$ btrfs receive -f /tmp/base.send /mnt/sdc
$ btrfs receive -vv -f /tmp/incr.send /mnt/sdc
(...)
truncate bar size=563200
utimes bar
clone zoo - source=bar source offset=512000 offset=0 length=51200
ERROR: failed to clone extents to zoo
Invalid argument
The failure happens because the clone source range ends at the eof of file
bar, 563200, which is not aligned to the filesystems sector size (4Kb in
this case), and the destination range ends at offset 0 + 51200, which is
less then the size of the file zoo (2Mb).
So fix this by detecting such case and instead of issuing a clone
operation for the whole range, do a clone operation for smaller range
that is sector size aligned followed by a write operation for the block
containing the eof. Here we will always be pessimistic and assume the
destination filesystem of the send stream has the largest possible sector
size (64Kb), since we have no way of determining it.
This fixes a recent regression introduced in kernel 5.2-rc1.
Fixes:
040ee6120cb6706 ("Btrfs: send, improve clone range")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Mon, 20 May 2019 08:55:42 +0000 (09:55 +0100)]
Btrfs: incremental send, fix file corruption when no-holes feature is enabled
When using the no-holes feature, if we have a file with prealloc extents
with a start offset beyond the file's eof, doing an incremental send can
cause corruption of the file due to incorrect hole detection. Such case
requires that the prealloc extent(s) exist in both the parent and send
snapshots, and that a hole is punched into the file that covers all its
extents that do not cross the eof boundary.
Example reproducer:
$ mkfs.btrfs -f -O no-holes /dev/sdb
$ mount /dev/sdb /mnt/sdb
$ xfs_io -f -c "pwrite -S 0xab 0 500K" /mnt/sdb/foobar
$ xfs_io -c "falloc -k 1200K 800K" /mnt/sdb/foobar
$ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/base
$ btrfs send -f /tmp/base.snap /mnt/sdb/base
$ xfs_io -c "fpunch 0 500K" /mnt/sdb/foobar
$ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/incr
$ btrfs send -p /mnt/sdb/base -f /tmp/incr.snap /mnt/sdb/incr
$ md5sum /mnt/sdb/incr/foobar
816df6f64deba63b029ca19d880ee10a /mnt/sdb/incr/foobar
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt/sdc
$ btrfs receive -f /tmp/base.snap /mnt/sdc
$ btrfs receive -f /tmp/incr.snap /mnt/sdc
$ md5sum /mnt/sdc/incr/foobar
cf2ef71f4a9e90c2f6013ba3b2257ed2 /mnt/sdc/incr/foobar
--> Different checksum, because the prealloc extent beyond the
file's eof confused the hole detection code and it assumed
a hole starting at offset 0 and ending at the offset of the
prealloc extent (1200Kb) instead of ending at the offset
500Kb (the file's size).
Fix this by ensuring we never cross the file's size when issuing the
write operations for a hole.
Fixes:
16e7549f045d33 ("Btrfs: incompatible format change to remove hole extents")
CC: stable@vger.kernel.org # 3.14+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Dennis Zhou [Fri, 17 May 2019 23:16:26 +0000 (19:16 -0400)]
btrfs: correct zstd workspace manager lock to use spin_lock_bh()
The btrfs zstd workspace manager uses a background timer to reclaim not
recently used workspaces. I used spin_lock() from this context which
should have been caught with lockdep, but was not. This deadlock was
reported in bugzilla. The fix is to switch the zstd wsm lock to use
spin_lock_bh() from the softirq context.
This happened quite relibably on ppc64, unlike on other architectures.
[ 313.402874] ================================
[ 313.402875] WARNING: inconsistent lock state
[ 313.402879] 5.1.0-rc7 #1 Not tainted
[ 313.402880] --------------------------------
[ 313.402882] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 313.402885] swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 313.402888]
0000000080d1120c (&(&wsm.lock)->rlock){+.?.}, at: .zstd_reclaim_timer_fn+0x40/0x230
[ 313.402895] {SOFTIRQ-ON-W} state was registered at:
[ 313.402899] .lock_acquire+0xd0/0x240
[ 313.402903] ._raw_spin_lock+0x34/0x60
[ 313.402906] .zstd_get_workspace+0xd0/0x360
[ 313.402908] .end_compressed_bio_read+0x3b8/0x540
[ 313.402911] .bio_endio+0x174/0x2c0
[ 313.402914] .end_workqueue_fn+0x4c/0x70
[ 313.402917] .normal_work_helper+0x138/0x7e0
[ 313.402920] .process_one_work+0x324/0x790
[ 313.402922] .worker_thread+0x68/0x570
[ 313.402925] .kthread+0x19c/0x1b0
[ 313.402928] .ret_from_kernel_thread+0x58/0x78
[ 313.402930] irq event stamp:
2629216
[ 313.402933] hardirqs last enabled at (
2629216): [<
c0000000009da738>] ._raw_spin_unlock_irq+0x38/0x60
[ 313.402936] hardirqs last disabled at (
2629215): [<
c0000000009da4c4>] ._raw_spin_lock_irq+0x24/0x70
[ 313.402939] softirqs last enabled at (
2629212): [<
c0000000000af9fc>] .irq_enter+0x8c/0xd0
[ 313.402942] softirqs last disabled at (
2629213): [<
c0000000000afb58>] .irq_exit+0x118/0x170
[ 313.402944]
other info that might help us debug this:
[ 313.402945] Possible unsafe locking scenario:
[ 313.402947] CPU0
[ 313.402948] ----
[ 313.402949] lock(&(&wsm.lock)->rlock);
[ 313.402951] <Interrupt>
[ 313.402952] lock(&(&wsm.lock)->rlock);
[ 313.402954]
*** DEADLOCK ***
[ 313.402957] 1 lock held by swapper/5/0:
[ 313.402958] #0:
000000004b612042 ((&wsm.timer)){+.-.}, at: .call_timer_fn+0x0/0x3c0
[ 313.402963]
stack backtrace:
[ 313.402967] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.1.0-rc7 #1
[ 313.402968] Call Trace:
[ 313.402972] [
c0000007fa262e70] [
c0000000009b3294] .dump_stack+0xe0/0x15c (unreliable)
[ 313.402975] [
c0000007fa262f10] [
c000000000125548] .print_usage_bug+0x348/0x390
[ 313.402978] [
c0000007fa262fd0] [
c000000000125cb4] .mark_lock+0x724/0x930
[ 313.402981] [
c0000007fa263080] [
c000000000126c20] .__lock_acquire+0xc90/0x16a0
[ 313.402984] [
c0000007fa2631b0] [
c000000000128040] .lock_acquire+0xd0/0x240
[ 313.402987] [
c0000007fa263280] [
c0000000009da2b4] ._raw_spin_lock+0x34/0x60
[ 313.402990] [
c0000007fa263300] [
c00000000054b0b0] .zstd_reclaim_timer_fn+0x40/0x230
[ 313.402993] [
c0000007fa2633d0] [
c000000000158b38] .call_timer_fn+0xc8/0x3c0
[ 313.402996] [
c0000007fa2634a0] [
c000000000158f74] .expire_timers+0x144/0x260
[ 313.402999] [
c0000007fa263550] [
c000000000159178] .run_timer_softirq+0xe8/0x230
[ 313.403002] [
c0000007fa263680] [
c0000000009db288] .__do_softirq+0x188/0x5d4
[ 313.403004] [
c0000007fa263790] [
c0000000000afb58] .irq_exit+0x118/0x170
[ 313.403008] [
c0000007fa263800] [
c000000000028d88] .timer_interrupt+0x158/0x430
[ 313.403012] [
c0000007fa2638b0] [
c0000000000091d4] decrementer_common+0x134/0x140
[ 313.403017] --- interrupt: 901 at replay_interrupt_return+0x0/0x4
LR = .arch_local_irq_restore.part.0+0x68/0x80
[ 313.403020] [
c0000007fa263bb0] [
c00000000001a3ac] .arch_local_irq_restore.part.0+0x2c/0x80 (unreliable)
[ 313.403024] [
c0000007fa263c30] [
c0000000007bbbcc] .cpuidle_enter_state+0xec/0x670
[ 313.403027] [
c0000007fa263d00] [
c0000000000f5130] .call_cpuidle+0x40/0x90
[ 313.403031] [
c0000007fa263d70] [
c0000000000f554c] .do_idle+0x2dc/0x3a0
[ 313.403034] [
c0000007fa263e30] [
c0000000000f59ac] .cpu_startup_entry+0x2c/0x30
[ 313.403037] [
c0000007fa263ea0] [
c000000000045674] .start_secondary+0x644/0x650
[ 313.403041] [
c0000007fa263f90] [
c00000000000ad5c] start_secondary_prolog+0x10/0x14
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203517
Fixes:
3f93aef535c8 ("btrfs: add zstd compression level support")
CC: stable@vger.kernel.org # 5.1+
Signed-off-by: Dennis Zhou <dennis@kernel.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Nikolay Borisov [Fri, 17 May 2019 07:44:25 +0000 (10:44 +0300)]
btrfs: Ensure replaced device doesn't have pending chunk allocation
Recent FITRIM work, namely
bbbf7243d62d ("btrfs: combine device update
operations during transaction commit") combined the way certain
operations are recoded in a transaction. As a result an ASSERT was added
in dev_replace_finish to ensure the new code works correctly.
Unfortunately I got reports that it's possible to trigger the assert,
meaning that during a device replace it's possible to have an unfinished
chunk allocation on the source device.
This is supposed to be prevented by the fact that a transaction is
committed before finishing the replace oepration and alter acquiring the
chunk mutex. This is not sufficient since by the time the transaction is
committed and the chunk mutex acquired it's possible to allocate a chunk
depending on the workload being executed on the replaced device. This
bug has been present ever since device replace was introduced but there
was never code which checks for it.
The correct way to fix is to ensure that there is no pending device
modification operation when the chunk mutex is acquire and if there is
repeat transaction commit. Unfortunately it's not possible to just
exclude the source device from btrfs_fs_devices::dev_alloc_list since
this causes ENOSPC to be hit in transaction commit.
Fixing that in another way would need to add special cases to handle the
last writes and forbid new ones. The looped transaction fix is more
obvious, and can be easily backported. The runtime of dev-replace is
long so there's no noticeable delay caused by that.
Reported-by: David Sterba <dsterba@suse.com>
Fixes:
391cd9df81ac ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Linus Torvalds [Tue, 28 May 2019 16:35:04 +0000 (09:35 -0700)]
Merge tag 'pinctrl-v5.2-2' of git://git./linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"The commits that stand out are the Intel fixes that arrived during the
merge window and I got relayed by pull request from Andy.
Apart from that a minor Kconfig noise.
- Interrupt clearing fix for the Intel pin controllers affecting
touchpads on some laptops.
- Compile Kconfig fix for the STMFX expander pin controller"
* tag 'pinctrl-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: stmfx: Fix compile issue when CONFIG_OF_GPIO is not defined
pinctrl: intel: Clear interrupt status in mask/unmask callback
pinctrl: intel: Use GENMASK() consistently
Linus Torvalds [Tue, 28 May 2019 16:33:05 +0000 (09:33 -0700)]
Merge tag 'gpio-v5.2-2' of git://git./linux/kernel/git/linusw/linux-gpio
Pull GPIO fix from Linus Walleij:
"Fix a build error in gpio-adp5588"
* tag 'gpio-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: fix gpio-adp5588 build errors
Randy Dunlap [Tue, 28 May 2019 16:14:30 +0000 (09:14 -0700)]
ia64: fix build errors by exporting paddr_to_nid()
Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by
exporting paddr_to_nid().
Fixes these build errors:
ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined!
ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined!
ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined!
ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined!
ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined!
ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined!
ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined!
ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined!
ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined!
ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined!
ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined!
ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined!
ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined!
ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined!
ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined!
ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined!
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ard Biesheuvel [Tue, 28 May 2019 14:13:16 +0000 (16:13 +0200)]
arm64/module: revert to unsigned interpretation of ABS16/32 relocations
Commit
1cf24a2cc3fd
("arm64/module: deal with ambiguity in PRELxx relocation ranges")
updated the overflow checking logic in the relocation handling code to
ensure that PREL16/32 relocations don't overflow signed quantities.
However, the same code path is used for absolute relocations, where the
interpretation is the opposite: the only current use case for absolute
relocations operating on non-native word size quantities is the CRC32
handling in the CONFIG_MODVERSIONS code, and these CRCs are unsigned
32-bit quantities, which are now being rejected by the module loader
if bit 31 happens to be set.
So let's use different ranges for quanties subject to absolute vs.
relative relocations:
- ABS16/32 relocations should be in the range [0, Uxx_MAX)
- PREL16/32 relocations should be in the range [Sxx_MIN, Sxx_MAX)
- otherwise, print an error since no other 16 or 32 bit wide data
relocations are currently supported.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Catalin Marinas [Tue, 28 May 2019 11:39:34 +0000 (12:39 +0100)]
arm64: Fix the arm64_personality() syscall wrapper redirection
Following commit
4378a7d4be30 ("arm64: implement syscall wrappers"), the
syscall function names gained the '__arm64_' prefix. Ensure that we
have the correct #define for redirecting a default syscall through a
wrapper.
Fixes:
4378a7d4be30 ("arm64: implement syscall wrappers")
Cc: <stable@vger.kernel.org> # 4.19.x-
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Takashi Iwai [Tue, 28 May 2019 06:39:44 +0000 (08:39 +0200)]
ALSA: line6: Assure canceling delayed work at disconnection
The current code performs the cancel of a delayed work at the late
stage of disconnection procedure, which may lead to the access to the
already cleared state.
This patch assures to call cancel_delayed_work_sync() at the beginning
of the disconnection procedure for avoiding that race. The delayed
work object is now assigned in the common line6 object instead of its
derivative, so that we can call cancel_delayed_work_sync().
Along with the change, the startup function is called via the new
callback instead. This will make it easier to port other LINE6
drivers to use the delayed work for startup in later patches.
Reported-by: syzbot+5255458d5e0a2b10bbb9@syzkaller.appspotmail.com
Fixes:
7f84ff68be05 ("ALSA: line6: toneport: Fix broken usage of timer for delayed execution")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sahitya Tummala [Thu, 3 Jan 2019 11:18:15 +0000 (16:48 +0530)]
configfs: Fix use-after-free when accessing sd->s_dentry
In the vfs_statx() context, during path lookup, the dentry gets
added to sd->s_dentry via configfs_attach_attr(). In the end,
vfs_statx() kills the dentry by calling path_put(), which invokes
configfs_d_iput(). Ideally, this dentry must be removed from
sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result,
sd->s_dentry is holding reference to a stale dentry pointer whose
memory is already freed up. This results in use-after-free issue,
when this stale sd->s_dentry is accessed later in
configfs_readdir() path.
This issue can be easily reproduced, by running the LTP test case -
sh fs_racer_file_list.sh /config
(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
Fixes:
76ae281f6307 ('configfs: fix race between dentry put and lookup')
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Bard Liao [Sun, 26 May 2019 16:58:32 +0000 (00:58 +0800)]
ALSA: hda - Force polling mode on CNL for fixing codec communication
We observed the same issue as reported by commit
a8d7bde23e7130686b7662
("ALSA: hda - Force polling mode on CFL for fixing codec communication")
We don't have a better solution. So apply the same workaround to CNL.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
David S. Miller [Mon, 27 May 2019 17:24:14 +0000 (10:24 -0700)]
Merge branch 'aquantia-fixes'
Igor Russkikh says:
====================
net: aquantia: various fixes May, 2019
Here is a set of various bug fixes found on recent verification stage.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Nikita Danilov [Sat, 25 May 2019 09:58:05 +0000 (09:58 +0000)]
net: aquantia: tcp checksum 0xffff being handled incorrectly
Thats a known quirk in windows tcp stack it can produce 0xffff checksum.
Thats incorrect but it is.
Atlantic HW with LRO enabled handles that incorrectly and changes csum to
0xfffe - but indicates that csum is invalid. This causes driver to pass
packet to linux networking stack with CSUM_NONE, stack eventually drops
the packet.
There is a quirk in atlantic HW to enable correct processing of
0xffff incorrect csum. Enable it.
The visible bug is that windows link partner with software generated csums
caused TCP connection to be unstable since all packets that csum value
are dropped.
Reported-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
Signed-off-by: Nikita Danilov <ndanilov@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dmitry Bogdanov [Sat, 25 May 2019 09:58:03 +0000 (09:58 +0000)]
net: aquantia: fix LRO with FCS error
Driver stops producing skbs on ring if a packet with FCS error
was coalesced into LRO session. Ring gets hang forever.
Thats a logical error in driver processing descriptors:
When rx_stat indicates MAC Error, next pointer and eop flags
are not filled. This confuses driver so it waits for descriptor 0
to be filled by HW.
Solution is fill next pointer and eop flag even for packets with FCS error.
Fixes:
bab6de8fd180b ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions.")
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dmitry Bogdanov [Sat, 25 May 2019 09:58:01 +0000 (09:58 +0000)]
net: aquantia: check rx csum for all packets in LRO session
Atlantic hardware does not aggregate nor breaks LRO sessions
with bad csum packets. This means driver should take care of that.
If in LRO session there is a non-first descriptor with invalid
checksum (L2/L3/L4), the driver must account this information
in csum application logic.
Fixes:
018423e90bee8 ("net: ethernet: aquantia: Add ring support code")
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Igor Russkikh [Sat, 25 May 2019 09:57:59 +0000 (09:57 +0000)]
net: aquantia: tx clean budget logic error
In case no other traffic happening on the ring, full tx cleanup
may not be completed. That may cause socket buffer to overflow
and tx traffic to stuck until next activity on the ring happens.
This is due to logic error in budget variable decrementor.
Variable is compared with zero, and then post decremented,
causing it to become MAX_INT. Solution is remove decrementor
from the `for` statement and rewrite it in a clear way.
Fixes:
b647d3980948e ("net: aquantia: Add tx clean budget and valid budget handling logic")
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Lucas Stach [Tue, 21 May 2019 12:53:40 +0000 (14:53 +0200)]
drm/etnaviv: lock MMU while dumping core
The devcoredump needs to operate on a stable state of the MMU while
it is writing the MMU state to the coredump. The missing lock
allowed both the userspace submit, as well as the GPU job finish
paths to mutate the MMU state while a coredump is under way.
Fixes:
a8c21a5451d8 (drm/etnaviv: add initial etnaviv DRM driver)
Reported-by: David Jander <david@protonic.nl>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: David Jander <david@protonic.nl>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Philipp Zabel [Thu, 9 May 2019 09:01:39 +0000 (11:01 +0200)]
drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q
The current buffer check halves the frame rate on non-plus i.MX6Q,
as the IDMAC current buffer pointer is not yet updated when
ipu_plane_atomic_update_pending is called from the EOF irq handler.
Fixes:
70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update status")
Tested-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: stable@vger.kernel.org
Gerd Hoffmann [Fri, 24 May 2019 10:42:50 +0000 (12:42 +0200)]
drm/qxl: drop WARN_ONCE()
There is no good reason to flood the kernel log with a WARN
stacktrace just because someone tried to mmap a prime buffer.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20190524104251.22761-1-kraxel@redhat.com
Linus Walleij [Mon, 27 May 2019 09:07:31 +0000 (11:07 +0200)]
Merge tag 'intel-pinctrl-v5.2-2' of git://git./linux/kernel/git/pinctrl/intel into fixes
intel-pinctrl for v5.2-2
Fix a laggish ELAN touchpad responsiveness due to an odd interrupt masking.
The following is an automated git shortlog grouped by driver:
intel:
- Clear interrupt status in mask/unmask callback
- Use GENMASK() consistently
Kees Cook [Fri, 24 May 2019 20:20:19 +0000 (13:20 -0700)]
net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE()
Building with Clang reports the redundant use of MODULE_DEVICE_TABLE():
drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table'
MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
^
./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
extern typeof(name) __mod_##type##__##name##_device_table \
^
<scratch space>:90:1: note: expanded from here
__mod_eisa__de4x5_eisa_ids_device_table
^
drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here
MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
^
./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
extern typeof(name) __mod_##type##__##name##_device_table \
^
<scratch space>:85:1: note: expanded from here
__mod_eisa__de4x5_eisa_ids_device_table
^
This drops the one further from the table definition to match the common
use of MODULE_DEVICE_TABLE().
Fixes:
07563c711fbc ("EISA bus MODALIAS attributes support")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 27 May 2019 04:47:13 +0000 (21:47 -0700)]
Merge branch 'net-tls-two-fixes-for-rx_list-pre-handling'
Jakub Kicinski says:
====================
net/tls: two fixes for rx_list pre-handling
tls_sw_recvmsg() had been modified to cater better to async decrypt.
Partially read records now live on the rx_list. Data is copied from
this list before the old do {} while loop, and the not included
correctly in deciding whether to sleep or not and lowat threshold
handling. These modifications, unfortunately, added some bugs.
First patch fixes lowat - we need to calculate the threshold early
and make sure all copied data is compared to the threshold, not just
the freshly decrypted data.
Third patch fixes sleep - if data is picked up from rx_list and
no flags are set, we should not put the process to sleep, but
rather return the partial read.
Patches 2 and 4 add test cases for these bugs, both will cause
a sleep and test timeout before the fix.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 24 May 2019 17:34:33 +0000 (10:34 -0700)]
selftests/tls: add test for sleeping even though there is data
Add a test which sends 15 bytes of data, and then tries
to read 10 byes twice. Previously the second read would
sleep indifinitely, since the record was already decrypted
and there is only 5 bytes left, not full 10.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 24 May 2019 17:34:32 +0000 (10:34 -0700)]
net/tls: fix no wakeup on partial reads
When tls_sw_recvmsg() partially copies a record it pops that
record from ctx->recv_pkt and places it on rx_list.
Next iteration of tls_sw_recvmsg() reads from rx_list via
process_rx_list() before it enters the decryption loop.
If there is no more records to be read tls_wait_data()
will put the process on the wait queue and got to sleep.
This is incorrect, because some data was already copied
in process_rx_list().
In case of RPC connections process may never get woken up,
because peer also simply blocks in read().
I think this may also fix a similar issue when BPF is at
play, because after __tcp_bpf_recvmsg() returns some data
we subtract it from len and use continue to restart the
loop, but len could have just reached 0, so again we'd
sleep unnecessarily. That's added by:
commit
d3b18ad31f93 ("tls: add bpf support to sk_msg handling")
Fixes:
692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
Reported-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Tested-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 24 May 2019 17:34:31 +0000 (10:34 -0700)]
selftests/tls: test for lowat overshoot with multiple records
Set SO_RCVLOWAT and test it gets respected when gathering
data from multiple records.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 24 May 2019 17:34:30 +0000 (10:34 -0700)]
net/tls: fix lowat calculation if some data came from previous record
If some of the data came from the previous record, i.e. from
the rx_list it had already been decrypted, so it's not counted
towards the "decrypted" variable, but the "copied" variable.
Take that into account when checking lowat.
When calculating lowat target we need to pass the original len.
E.g. if lowat is at 80, len is 100 and we had 30 bytes on rx_list
target would currently be incorrectly calculated as 70, even though
we only need 50 more bytes to make up the 80.
Fixes:
692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Tested-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Sun, 26 May 2019 23:49:19 +0000 (16:49 -0700)]
Linux 5.2-rc2
Linus Torvalds [Sun, 26 May 2019 20:49:40 +0000 (13:49 -0700)]
Merge tag 'trace-v5.2-rc1-2' of git://git./linux/kernel/git/rostedt/linux-trace
Pull tracing warning fix from Steven Rostedt:
"Make the GCC 9 warning for sub struct memset go away.
GCC 9 now warns about calling memset() on partial structures when it
goes across multiple fields. This adds a helper for the place in
tracing that does this type of clearing of a structure"
* tag 'trace-v5.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Silence GCC 9 array bounds warning
Linus Torvalds [Sun, 26 May 2019 20:45:15 +0000 (13:45 -0700)]
Merge tag 'for-linus' of git://git./virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"The usual smattering of fixes and tunings that came in too late for
the merge window, but should not wait four months before they appear
in a release.
I also travelled a bit more than usual in the first part of May, which
didn't help with picking up patches and reports promptly"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (33 commits)
KVM: x86: fix return value for reserved EFER
tools/kvm_stat: fix fields filter for child events
KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86 guard
kvm: selftests: aarch64: compile with warnings on
kvm: selftests: aarch64: fix default vm mode
kvm: selftests: aarch64: dirty_log_test: fix unaligned memslot size
KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION
KVM: x86/pmu: do not mask the value that is written to fixed PMUs
KVM: x86/pmu: mask the result of rdpmc according to the width of the counters
x86/kvm/pmu: Set AMD's virt PMU version to 1
KVM: x86: do not spam dmesg with VMCS/VMCB dumps
kvm: Check irqchip mode before assign irqfd
kvm: svm/avic: fix off-by-one in checking host APIC ID
KVM: selftests: do not blindly clobber registers in guest asm
KVM: selftests: Remove duplicated TEST_ASSERT in hyperv_cpuid.c
KVM: LAPIC: Expose per-vCPU timer_advance_ns to userspace
KVM: LAPIC: Fix lapic_timer_advance_ns parameter overflow
kvm: vmx: Fix -Wmissing-prototypes warnings
KVM: nVMX: Fix using __this_cpu_read() in preemptible context
kvm: fix compilation on s390
...