aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-07net/sched: act_ct: add miss tcf_lastuse_update.wenxu1-0/+2
When tcf_ct_act execute the tcf_lastuse_update should be update or the used stats never update filter protocol ip pref 3 flower chain 0 filter protocol ip pref 3 flower chain 0 handle 0x1 eth_type ipv4 dst_ip 1.1.1.1 ip_flags frag/firstfrag skip_hw not_in_hw action order 1: ct zone 1 nat pipe index 1 ref 1 bind 1 installed 103 sec used 103 sec Action statistics: Sent 151500 bytes 101 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 cookie 4519c04dc64a1a295787aab13b6a50fb Signed-off-by: wenxu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07net/mlx5e: Do not include rwlock.h directlySebastian Andrzej Siewior1-1/+0
rwlock.h should not be included directly. Instead linux/splinlock.h should be included. Including it directly will break the RT build. Fixes: 549c243e4e010 ("net/mlx5e: Extract neigh-specific code from en_rep.c to rep/neigh.c") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Acked-by: Saeed Mahameed <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07mptcp: fix DSS map generation on fin retransmissionPaolo Abeni1-3/+3
The RFC 8684 mandates that no-data DATA FIN packets should carry a DSS with 0 sequence number and data len equal to 1. Currently, on FIN retransmission we re-use the existing mapping; if the previous fin transmission was part of a partially acked data packet, we could end-up writing in the egress packet a non-compliant DSS. The above will be detected by a "Bad mapping" warning on the receiver side. This change addresses the issue explicitly checking for 0 len packet when adding the DATA_FIN option. Fixes: 6d0060f600ad ("mptcp: Write MPTCP DSS headers to outgoing data packets") Reported-by: [email protected] Tested-by: Christoph Paasch <[email protected]> Reviewed-by: Christoph Paasch <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07ipv4: fill fl4_icmp_{type,code} in ping_v4_sendmsgSabrina Dubroca1-0/+3
IPv4 ping sockets don't set fl4.fl4_icmp_{type,code}, which leads to incomplete IPsec ACQUIRE messages being sent to userspace. Currently, both raw sockets and IPv6 ping sockets set those fields. Expected output of "ip xfrm monitor": acquire proto esp sel src 10.0.2.15/32 dst 8.8.8.8/32 proto icmp type 8 code 0 dev ens4 policy src 10.0.2.15/32 dst 8.8.8.8/32 <snip> Currently with ping sockets: acquire proto esp sel src 10.0.2.15/32 dst 8.8.8.8/32 proto icmp type 0 code 0 dev ens4 policy src 10.0.2.15/32 dst 8.8.8.8/32 <snip> The Libreswan test suite found this problem after Fedora changed the value for the sysctl net.ipv4.ping_group_range. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Reported-by: Paul Wouters <[email protected]> Tested-by: Paul Wouters <[email protected]> Signed-off-by: Sabrina Dubroca <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07net: ethernet: fec: prevent tx starvation under high rx loadTobias Waldekranz2-68/+31
In the ISR, we poll the event register for the queues in need of service and then enter polled mode. After this point, the event register will never be read again until we exit polled mode. In a scenario where a UDP flow is routed back out through the same interface, i.e. "router-on-a-stick" we'll typically only see an rx queue event initially. Once we start to process the incoming flow we'll be locked polled mode, but we'll never clean the tx rings since that event is never caught. Eventually the netdev watchdog will trip, causing all buffers to be dropped and then the process starts over again. Rework the NAPI poll to keep trying to consome the entire budget as long as new events are coming in, making sure to service all rx/tx queues, in priority order, on each pass. Fixes: 4d494cdc92b3 ("net: fec: change data structure to support multiqueue") Signed-off-by: Tobias Waldekranz <[email protected]> Tested-by: Fugang Duan <[email protected]> Reviewed-by: Fugang Duan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07net: sky2: initialize return of gm_phy_readTom Rix1-1/+1
clang static analysis flags this garbage return drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return v; ^~~~~~~~ static inline u16 gm_phy_read( ... { u16 v; __gm_phy_read(hw, port, reg, &v); return v; } __gm_phy_read can return without setting v. So handle similar to skge.c's gm_phy_read, initialize v. Signed-off-by: Tom Rix <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07Merge tag 'mtd/fixes-for-5.8-rc5' of ↵Linus Torvalds3-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "MTD: - Set a missing master partition panic write flag Raw NAND: - Fix build issue in the xway driver - Fix a wrong return code" * tag 'mtd/fixes-for-5.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: xway: Fix build issue mtd: set master partition panic write flag nandsim: Fix return code testing of ns_find_operation()
2020-07-07gfs2: Rework read and page fault lockingAndreas Gruenbacher2-46/+51
So far, gfs2 has taken the inode glocks inside the ->readpage and ->readahead address space operations. Since commit d4388340ae0b ("fs: convert mpage_readpages to mpage_readahead"), gfs2_readahead is passed the pages to read ahead locked. With that, the current holder of the inode glock may be trying to lock one of those pages while gfs2_readahead is trying to take the inode glock, resulting in a deadlock. Fix that by moving the lock taking to the higher-level ->read_iter file and ->fault vm operations. This also gets rid of an ugly lock inversion workaround in gfs2_readpage. The cache consistency model of filesystems like gfs2 is such that if data is found in the page cache, the data is up to date and can be used without taking any filesystem locks. If a page is not cached, filesystem locks must be taken before populating the page cache. To avoid taking the inode glock when the data is already cached, gfs2_file_read_iter first tries to read the data with the IOCB_NOIO flag set. If that fails, the inode glock is taken and the operation is retried with the IOCB_NOIO flag cleared. Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-07-07fs: Add IOCB_NOIO flag for generic_file_read_iterAndreas Gruenbacher2-2/+22
Add an IOCB_NOIO flag that indicates to generic_file_read_iter that it shouldn't trigger any filesystem I/O for the actual request or for readahead. This allows to do tentative reads out of the page cache as some filesystems allow, and to take the appropriate locks and retry the reads only if the requested pages are not cached. Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-07-07Merge tag 'for-5.8-rc4-tag' of ↵Linus Torvalds7-25/+35
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - regression fix of a leak in global block reserve accounting - fix a (hard to hit) race of readahead vs releasepage that could lead to crash - convert all remaining uses of comment fall through annotations to the pseudo keyword - fix crash when mounting a fuzzed image with -o recovery * tag 'for-5.8-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: reset tree root pointer after error in init_tree_roots btrfs: fix reclaim_size counter leak after stealing from global reserve btrfs: fix fatal extent_buffer readahead vs releasepage race btrfs: convert comments to fallthrough annotations
2020-07-07Merge tag 'arc-5.8-rc5' of ↵Linus Torvalds7-27/+59
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - User build systems to pass -mcpu - Fix potential EFA clobber in syscall handler - Fix ARCompact 2 levels of interrupts build - Detect newer HS CPU releases - misc other fixes * tag 'arc-5.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARCv2: support loop buffer (LPB) disabling ARC: build: remove deprecated toggle for arc700 builds ARC: build: allow users to specify -mcpu ARCv2: boot log: detect newer/upconing HS3x/HS4x releases ARC: elf: use right ELF_ARCH ARC: [arcompact] fix bitrot with 2 levels of interrupt ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE
2020-07-07cgroup: fix cgroup_sk_alloc() for sk_clone_lock()Cong Wang4-16/+27
When we clone a socket in sk_clone_lock(), its sk_cgrp_data is copied, so the cgroup refcnt must be taken too. And, unlike the sk_alloc() path, sock_update_netprioidx() is not called here. Therefore, it is safe and necessary to grab the cgroup refcnt even when cgroup_sk_alloc is disabled. sk_clone_lock() is in BH context anyway, the in_interrupt() would terminate this function if called there. And for sk_alloc() skcd->val is always zero. So it's safe to factor out the code to make it more readable. The global variable 'cgroup_sk_alloc_disabled' is used to determine whether to take these reference counts. It is impossible to make the reference counting correct unless we save this bit of information in skcd->val. So, add a new bit there to record whether the socket has already taken the reference counts. This obviously relies on kmalloc() to align cgroup pointers to at least 4 bytes, ARCH_KMALLOC_MINALIGN is certainly larger than that. This bug seems to be introduced since the beginning, commit d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets") tried to fix it but not compeletely. It seems not easy to trigger until the recent commit 090e28b229af ("netprio_cgroup: Fix unlimited memory leak of v2 cgroups") was merged. Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup") Reported-by: Cameron Berkenpas <[email protected]> Reported-by: Peter Geis <[email protected]> Reported-by: Lu Fengqi <[email protected]> Reported-by: Daniël Sonck <[email protected]> Reported-by: Zhang Qiang <[email protected]> Tested-by: Cameron Berkenpas <[email protected]> Tested-by: Peter Geis <[email protected]> Tested-by: Thomas Lamprecht <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Zefan Li <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Roman Gushchin <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07Merge tag 'tpmdd-next-v5.8-rc5' of git://git.infradead.org/users/jjs/linux-tpmddLinus Torvalds1-0/+8
Pull tpm fix from Jarkko Sakkinen: "Revert commit e918e570415c ("tpm_tis: Remove the HID IFX0102"). Removing IFX0102 from tpm_tis was not a right move because both tpm_tis and tpm_infineon use the same device ID. A real fix requires quirks added to both drivers. It can probably wait until v5.9 as the bug has existed since 2006" * tag 'tpmdd-next-v5.8-rc5' of git://git.infradead.org/users/jjs/linux-tpmdd: Revert commit e918e570415c ("tpm_tis: Remove the HID IFX0102")
2020-07-07ipv6: Fix use of anycast address with loopbackDavid Ahern1-1/+1
Thomas reported a regression with IPv6 and anycast using the following reproducer: echo 1 > /proc/sys/net/ipv6/conf/all/forwarding ip -6 a add fc12::1/16 dev lo sleep 2 echo "pinging lo" ping6 -c 2 fc12:: The conversion of addrconf_f6i_alloc to use ip6_route_info_create missed the use of fib6_is_reject which checks addresses added to the loopback interface and sets the REJECT flag as needed. Update fib6_is_reject for loopback checks to handle RTF_ANYCAST addresses. Fixes: c7a1ce397ada ("ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create") Reported-by: [email protected] Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07net: usb: qmi_wwan: add support for Quectel EG95 LTE modemAceLan Kao1-0/+1
Add support for Quectel Wireless Solutions Co., Ltd. EG95 LTE modem T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0195 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: AceLan Kao <[email protected]> Acked-by: Bjørn Mork <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07Merge branch 'net-ipa-fix-warning-reported-errors'David S. Miller3-3/+6
Alex Elder says: ==================== net: ipa: fix warning-reported errors Building the kernel with W=1 produces numerous warnings for the IPA code. Some of those warnings turn out to flag real problems, and this series fixes them. The first patch fixes the most important ones, but the second and third are problems I think are worth treating as bugs as well. Note: I'll happily combine any of these if someone prefers that. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-07-07net: ipa: include declarations in "ipa_gsi.c"Alex Elder1-0/+1
Include "ipa_gsi.h" in "ipa_gsi.c", so the public functions are defined before they are used in "ipa_gsi.c". This addresses some warnings that are reported with a "W=1" build. Fixes: c3f398b141a8 ("soc: qcom: ipa: IPA interface to GSI") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07net: ipa: declare struct types in "ipa_gsi.h"Alex Elder1-0/+2
Pointers to two struct types are used in "ipa_gsi.h", without those struct types being forward-declared. Add these declarations. Fixes: c3f398b141a8 ("soc: qcom: ipa: IPA interface to GSI") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07net: ipa: fix QMI structure definition bugsAlex Elder1-3/+3
Building with "W=1" did exactly what it was supposed to do, namely point out some suspicious-looking code to be verified not to contain bugs. Some QMI message structures defined in "ipa_qmi_msg.c" contained some bad field names (duplicating the "elem_size" field instead of defining the "offset" field), almost certainly due to copy/paste errors that weren't obvious in a scan of the code. Fix these bugs. Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-07mtd: rawnand: xway: Fix build issueMiquel Raynal1-1/+1
This MIPS driver does not support COMPILE_TEST yet and failed to build under my radar. Replace 'mtd' chich is not defined in the scope of xway_nand_remove() by nand_to_mtd(chip). The mistake has been added in the long series dropping nand_release(). Tested with a 7.3.0 MIPS GCC toolchain built with Buildroot. Fixes: 9fdd78f7bcda ("mtd: rawnand: xway: Stop using nand_release()") Reported-by: kernel test robot <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2020-07-07dm: do not use waitqueue for request-based DMMing Lei2-29/+39
Given request-based DM now uses blk-mq's blk_mq_queue_inflight() to determine if outstanding IO has completed (and DM has no control over the blk-mq state machine used to track outstanding IO) it is unsafe to wakeup waiter (dm_wait_for_completion) before blk-mq has cleared a request's state bits (e.g. MQ_RQ_IN_FLIGHT or MQ_RQ_COMPLETE). As such dm_wait_for_completion() could be left to wait indefinitely if no other requests complete. Fix this by eliminating request-based DM's use of waitqueue to wait for blk-mq requests to complete in dm_wait_for_completion. Signed-off-by: Ming Lei <[email protected]> Depends-on: 3c94d83cb3526 ("blk-mq: change blk_mq_queue_busy() to blk_mq_queue_inflight()") Cc: [email protected] Signed-off-by: Mike Snitzer <[email protected]>
2020-07-07blk-mq: consider non-idle request as "inflight" in blk_mq_rq_inflight()Ming Lei1-2/+2
dm-multipath is the only user of blk_mq_queue_inflight(). When dm-multipath calls blk_mq_queue_inflight() to check if it has outstanding IO it can get a false negative. The reason for this is blk_mq_rq_inflight() doesn't consider requests that are no longer MQ_RQ_IN_FLIGHT but that are now MQ_RQ_COMPLETE (->complete isn't called or finished yet) as "inflight". This causes request-based dm-multipath's dm_wait_for_completion() to return before all outstanding dm-multipath requests have actually completed. This breaks DM multipath's suspend functionality because blk-mq requests complete after DM's suspend has finished -- which shouldn't happen. Fix this by considering any request not in the MQ_RQ_IDLE state (so either MQ_RQ_COMPLETE or MQ_RQ_IN_FLIGHT) as "inflight" in blk_mq_rq_inflight(). Fixes: 3c94d83cb3526 ("blk-mq: change blk_mq_queue_busy() to blk_mq_queue_inflight()") Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]>
2020-07-07btrfs: discard: add missing put when grabbing block group from unused listQu Wenruo1-0/+1
[BUG] The following small test script can trigger ASSERT() at unmount time: mkfs.btrfs -f $dev mount $dev $mnt mount -o remount,discard=async $mnt umount $mnt The call trace: assertion failed: atomic_read(&block_group->count) == 1, in fs/btrfs/block-group.c:3431 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.h:3204! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 10389 Comm: umount Tainted: G O 5.8.0-rc3-custom+ #68 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: btrfs_free_block_groups.cold+0x22/0x55 [btrfs] close_ctree+0x2cb/0x323 [btrfs] btrfs_put_super+0x15/0x17 [btrfs] generic_shutdown_super+0x72/0x110 kill_anon_super+0x18/0x30 btrfs_kill_super+0x17/0x30 [btrfs] deactivate_locked_super+0x3b/0xa0 deactivate_super+0x40/0x50 cleanup_mnt+0x135/0x190 __cleanup_mnt+0x12/0x20 task_work_run+0x64/0xb0 __prepare_exit_to_usermode+0x1bc/0x1c0 __syscall_return_slowpath+0x47/0x230 do_syscall_64+0x64/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The code: ASSERT(atomic_read(&block_group->count) == 1); btrfs_put_block_group(block_group); [CAUSE] Obviously it's some btrfs_get_block_group() call doesn't get its put call. The offending btrfs_get_block_group() happens here: void btrfs_mark_bg_unused(struct btrfs_block_group *bg) { if (list_empty(&bg->bg_list)) { btrfs_get_block_group(bg); list_add_tail(&bg->bg_list, &fs_info->unused_bgs); } } So every call sites removing the block group from unused_bgs list should reduce the ref count of that block group. However for async discard, it didn't follow the call convention: void btrfs_discard_punt_unused_bgs_list(struct btrfs_fs_info *fs_info) { list_for_each_entry_safe(block_group, next, &fs_info->unused_bgs, bg_list) { list_del_init(&block_group->bg_list); btrfs_discard_queue_work(&fs_info->discard_ctl, block_group); } } And in btrfs_discard_queue_work(), it doesn't call btrfs_put_block_group() either. [FIX] Fix the problem by reducing the reference count when we grab the block group from unused_bgs list. Reported-by: Marcos Paulo de Souza <[email protected]> Fixes: 6e80d4f8c422 ("btrfs: handle empty block_group removal for async discard") CC: [email protected] # 5.6+ Tested-by: Marcos Paulo de Souza <[email protected]> Reviewed-by: Anand Jain <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-07-07ALSA: compress: fix partial_drain completion stateVinod Koul2-1/+13
On partial_drain completion we should be in SNDRV_PCM_STATE_RUNNING state, so set that for partially draining streams in snd_compr_drain_notify() and use a flag for partially draining streams While at it, add locks for stream state change in snd_compr_drain_notify() as well. Fixes: f44f2a5417b2 ("ALSA: compress: fix drain calls blocking other compress functions (v6)") Reviewed-by: Srinivas Kandagatla <[email protected]> Tested-by: Srinivas Kandagatla <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Tested-by: Charles Keepax <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: usb-audio: Add implicit feedback quirk for RTX6001Pavel Hofman1-0/+1
USB Audio analyzer RTX6001 uses the same implicit feedback quirk as other XMOS-based devices. Signed-off-by: Pavel Hofman <[email protected]> Tested-by: Pavel Hofman <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: usb-audio: add quirk for MacroSilicon MS2109Hector Martin1-0/+52
These devices claim to be 96kHz mono, but actually are 48kHz stereo with swapped channels and unaligned transfers. Cc: [email protected] Signed-off-by: Hector Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: hda/realtek: Enable headset mic of Acer Veriton N4660G with ALC269VCJian-Hong Pan1-0/+11
The Acer Veriton N4660G desktop's audio (1025:1248) with ALC269VC cannot detect the headset microphone until ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE quirk maps the NID 0x18 as the headset mic pin. Signed-off-by: Jian-Hong Pan <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: hda/realtek: Enable headset mic of Acer C20-820 with ALC269VCJian-Hong Pan1-0/+11
The Acer Aspire C20-820 AIO's audio (1025:1065) with ALC269VC can't detect the headset microphone until ALC269VC_FIXUP_ACER_HEADSET_MIC quirk maps the NID 0x18 as the headset mic pin. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Daniel Drake <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: hda/realtek - Enable audio jacks of Acer vCopperbox with ALC269VCJian-Hong Pan1-0/+13
The Acer desktop vCopperbox with ALC269VC cannot detect the MIC of headset, the line out and internal speaker until ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS quirk applied. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Chris Chiu <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk subdevice idBenjamin Poirier1-2/+1
1) In snd_hda_pick_fixup(), quirks are first matched by PCI SSID and then, if there is no match, by codec SSID. The Lenovo "ThinkPad X1 Carbon 7th" has an audio chip with PCI SSID 0x2292 and codec SSID 0x2293[1]. Therefore, fix the quirk meant for that device to match on .subdevice == 0x2292. 2) The "Thinkpad X1 Yoga 7th" does not exist. The companion product to the Carbon 7th is the Yoga 4th. That device has an audio chip with PCI SSID 0x2292 and codec SSID 0x2292[2]. Given the behavior of snd_hda_pick_fixup(), it is not possible to have a separate quirk for the Yoga based on SSID. Therefore, merge the quirks meant for the Carbon and Yoga. This preserves the current behavior for the Yoga. [1] This is the case on my own machine and can also be checked here https://github.com/linuxhw/LsPCI/tree/master/Notebook/Lenovo/ThinkPad https://gist.github.com/hamidzr/dd81e429dc86f4327ded7a2030e7d7d9#gistcomment-3225701 [2] https://github.com/linuxhw/LsPCI/tree/master/Convertible/Lenovo/ThinkPad https://gist.github.com/hamidzr/dd81e429dc86f4327ded7a2030e7d7d9#gistcomment-3176355 Fixes: d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") Fixes: 54a6a7dc107d ("ALSA: hda/realtek - Add quirk for the bass speaker on Lenovo Yoga X1 7th gen") Cc: Jaroslav Kysela <[email protected]> Cc: Kailang Yang <[email protected]> Tested-by: Vincent Bernat <[email protected]> Tested-by: Even Brenden <[email protected]> Signed-off-by: Benjamin Poirier <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: hda/hdmi: improve debug traces for stream lookupsKai Vehmanen1-2/+3
The HDMI codec driver has two debug traces printed from different functions but with identical message content: "HDMI: hinfo 000000006a6b84d9 not registered" Fix this duplication and also add a bit more context in addition to raw object pointer, to help analysis of kernel logs. Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Kai Vehmanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: hda/hdmi: fix failures at PCM open on Intel ICL and laterKai Vehmanen1-13/+23
When HDMI PCM devices are opened in a specific order, with at least one HDMI/DP receiver connected, ALSA PCM open fails to -EBUSY on the connected monitor, on recent Intel platforms (ICL/JSL and newer). While this is not a typical sequence, at least Pulseaudio does this every time when it is started, to discover the available PCMs. The rootcause is an invalid assumption in hdmi_add_pin(), where the total number of converters is assumed to be known at the time the function is called. On older Intel platforms this held true, but after ICL/JSL, the order how pins and converters are in the subnode list as returned by snd_hda_get_sub_nodes(), was changed. As a result, information for some converters was not stored to per_pin->mux_nids. And this means some pins cannot be connected to all converters, and application instead gets -EBUSY instead at open. The assumption that converters are always before pins in the subnode list, is not really a valid one. Fix the problem in hdmi_parse_codec() by introducing separate loops for discovering converters and pins. BugLink: https://github.com/thesofproject/linux/issues/1978 BugLink: https://github.com/thesofproject/linux/issues/2216 BugLink: https://github.com/thesofproject/linux/issues/2217 Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Kai Vehmanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07ALSA: opl3: fix infoleak in opl3xidongwang1-0/+2
The stack object “info” in snd_opl3_ioctl() has a leaking problem. It has 2 padding bytes which are not initialized and leaked via “copy_to_user”. Signed-off-by: xidongwang <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-07-07Revert commit e918e570415c ("tpm_tis: Remove the HID IFX0102")Jarkko Sakkinen1-0/+8
Removing IFX0102 from tpm_tis was not a right move because both tpm_tis and tpm_infineon use the same device ID. Revert the commit and add a remark about a bug caused by commit 93e1b7d42e1e ("[PATCH] tpm: add HID module parameter"). Fixes: e918e570415c ("tpm_tis: Remove the HID IFX0102") Reported-by: Peter Huewe <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-06drm/i915: Also drop vm.ref along error paths for vma constructionChris Wilson1-10/+6
Not only do we need to release the vm.ref we acquired for the vma on the duplicate insert branch, but also for the normal error paths, so roll them all into one. Reported-by: Andi Shyti <[email protected]> Suggested-by: Andi Shyti <[email protected]> Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Cc: <[email protected]> # v5.5+ Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 03fca66b7a36b52da8915341eee388267f6d5b73) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-07-06drm/i915: Drop vm.ref for duplicate vma on constructionChris Wilson1-0/+1
As we allow for parallel threads to create the same vma instance concurrently, and we only filter out the duplicates upon reacquiring the spinlock for the rbtree, we have to free the loser of the constructors' race. When freeing, we should also drop any resource references acquired for the redundant vma. Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.5+ Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2377427cdd2b7514eb4c40241cf5c4dec63c1bec) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-07-06drm/i915/fbc: Fix fence_y_offset handlingVille Syrjälä4-25/+25
The current fence_y_offset calculation is broken. I think it more or less used to do the right thing, but then I changed the plane code to put the final x/y source offsets back into the src rectangle so now it's just subtraacting the same value from itself. The code would never have worked if we allowed the framebuffer to have a non-zero offset. Let's do this in a better way by just calculating the fence_y_offset from the final plane surface offset. Note that we don't align the plane surface address to fence rows so with horizontal panning there's often a horizontal offset from the fence start to the surface address as well. We have no way to tell the hardware about that so we just ignore it. Based on some quick tests the invlidation still happens correctly. I presume due to the invalidation nuking at least the full line (or a segment of multiple lines). Fixes: 54d4d719fa11 ("drm/i915: Overcome display engine stride limits via GTT remapping") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matt Roper <[email protected]> (cherry picked from commit 5331889b5ffb11d6257953e418291a9f04c02bed) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-07-06drm/i915: Skip stale object handle for debugfs per-file-statsChris Wilson1-1/+1
As we close a handle GEM object, we update the drm_file's idr with an error^W NULL pointer to indicate the in-progress closure, and finally removing it. If we read the idr directly, we may then see an invalid object pointer, and in our debugfs per_file_stats() we therefore need to protect against the entry being invalid. [ 1016.651637] RIP: 0010:per_file_stats+0xe/0x16e [ 1016.651646] Code: d2 41 0f b6 8e 69 8c 00 00 48 89 df 48 c7 c6 7b 74 8c be 31 c0 e8 0c 89 cf ff eb d2 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 <8b> 06 85 c0 0f 84 4d 01 00 00 49 89 d6 48 89 f3 3d ff ff ff 7f 73 [ 1016.651651] RSP: 0018:ffffad3a01337ba0 EFLAGS: 00010293 [ 1016.651656] RAX: 0000000000000018 RBX: ffff96fe040d65e0 RCX: 0000000000000002 [ 1016.651660] RDX: ffffad3a01337c50 RSI: 0000000000000000 RDI: 00000000000001e8 [ 1016.651663] RBP: ffffad3a01337bb8 R08: 0000000000000000 R09: 00000000000001c0 [ 1016.651667] R10: 0000000000000000 R11: ffffffffbdbe5fce R12: 0000000000000000 [ 1016.651671] R13: ffffffffbdbe5fce R14: ffffad3a01337c50 R15: 0000000000000001 [ 1016.651676] FS: 00007a597e2d7480(0000) GS:ffff96ff3bb00000(0000) knlGS:0000000000000000 [ 1016.651680] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1016.651683] CR2: 0000000000000000 CR3: 0000000171fc2001 CR4: 00000000003606e0 [ 1016.651687] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1016.651690] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1016.651693] Call Trace: [ 1016.651693] Call Trace: [ 1016.651703] idr_for_each+0x8a/0xe8 [ 1016.651711] i915_gem_object_info+0x2a3/0x3eb [ 1016.651720] seq_read+0x162/0x3ca [ 1016.651727] full_proxy_read+0x5b/0x8d [ 1016.651733] __vfs_read+0x45/0x1bb [ 1016.651741] vfs_read+0xc9/0x15e [ 1016.651746] ksys_read+0x7e/0xde [ 1016.651752] do_syscall_64+0x54/0x68 [ 1016.651758] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by: Guenter Roeck <[email protected]> Fixes: a8c15954d64a ("drm/i915: Protect debugfs per_file_stats with RCU lock") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: [email protected] Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c1b9fd3d310177b31621d5e661f06885869cae12) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-07-06kselftest: ksft_test_num return type should be unsignedPaolo Bonzini1-1/+1
Fixes a compiler warning: In file included from sync_test.c:37: ../kselftest.h: In function ‘ksft_print_cnts’: ../kselftest.h:78:16: warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] if (ksft_plan != ksft_test_num()) ^~ Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2020-07-06ipv6: fib6_select_path can not use out path for nexthop objectsDavid Ahern2-1/+17
Brian reported a crash in IPv6 code when using rpfilter with a setup running FRR and external nexthop objects. The root cause of the crash is fib6_select_path setting fib6_nh in the result to NULL because of an improper check for nexthop objects. More specifically, rpfilter invokes ip6_route_lookup with flowi6_oif set causing fib6_select_path to be called with have_oif_match set. fib6_select_path has early check on have_oif_match and jumps to the out label which presumes a builtin fib6_nh. This path is invalid for nexthop objects; for external nexthops fib6_select_path needs to just return if the fib6_nh has already been set in the result otherwise it returns after the call to nexthop_path_fib6_result. Update the check on have_oif_match to not bail on external nexthops. Update selftests for this problem. Fixes: f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info") Reported-by: Brian Rak <[email protected]> Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-06selftests: tpm: upgrade TPM2 tests from Python 2 to Python 3Pengfei Xu4-49/+52
Python 2 is no longer supported by the Python upstream project, so upgrade TPM2 tests to Python 3. Fixed minor merge conflicts Shuah Khan <[email protected]> Signed-off-by: Pengfei Xu <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2020-07-06Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds15-30/+70
Pull kvm fixes from Paolo Bonzini: "Bugfixes and a one-liner patch to silence a sparse warning" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: arm64: Stop clobbering x0 for HVC_SOFT_RESTART KVM: arm64: PMU: Fix per-CPU access in preemptible context KVM: VMX: Use KVM_POSSIBLE_CR*_GUEST_BITS to initialize guest/host masks KVM: x86: Mark CR4.TSD as being possibly owned by the guest KVM: x86: Inject #GP if guest attempts to toggle CR4.LA57 in 64-bit mode kvm: use more precise cast and do not drop __user KVM: x86: bit 8 of non-leaf PDPEs is not reserved KVM: X86: Fix async pf caused null-ptr-deref KVM: arm64: vgic-v4: Plug race between non-residency and v4.1 doorbell KVM: arm64: pvtime: Ensure task delay accounting is enabled KVM: arm64: Fix kvm_reset_vcpu() return code being incorrect with SVE KVM: arm64: Annotate hyp NMI-related functions as __always_inline KVM: s390: reduce number of IO pins to 1
2020-07-06Merge branch 'hns3-fixes'David S. Miller4-6/+13
Huazhong Tan says: ==================== net: hns3: fixes for -net There are some fixes about reset issue and a use-after-free of self-test. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-07-06net: hns3: fix use-after-free when doing self testYonglong Liu1-3/+6
Enable promisc mode of PF, set VF link state to enable, and run iperf of the VF, then do self test of the PF. The self test will fail with a low frequency, and may cause a use-after-free problem. [ 87.142126] selftest:000004a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 87.159722] ================================================================== [ 87.174187] BUG: KASAN: use-after-free in hex_dump_to_buffer+0x140/0x608 [ 87.187600] Read of size 1 at addr ffff003b22828000 by task ethtool/1186 [ 87.201012] [ 87.203978] CPU: 7 PID: 1186 Comm: ethtool Not tainted 5.5.0-rc4-gfd51c473-dirty #4 [ 87.219306] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.B160.01 01/15/2020 [ 87.238292] Call trace: [ 87.243173] dump_backtrace+0x0/0x280 [ 87.250491] show_stack+0x24/0x30 [ 87.257114] dump_stack+0xe8/0x140 [ 87.263911] print_address_description.isra.8+0x70/0x380 [ 87.274538] __kasan_report+0x12c/0x230 [ 87.282203] kasan_report+0xc/0x18 [ 87.288999] __asan_load1+0x60/0x68 [ 87.295969] hex_dump_to_buffer+0x140/0x608 [ 87.304332] print_hex_dump+0x140/0x1e0 [ 87.312000] hns3_lb_check_skb_data+0x168/0x170 [ 87.321060] hns3_clean_rx_ring+0xa94/0xfe0 [ 87.329422] hns3_self_test+0x708/0x8c0 The length of packet sent by the selftest process is only 128 + 14 bytes, and the min buffer size of a BD is 256 bytes, and the receive process will make sure the packet sent by the selftest process is in the linear part, so only check the linear part in hns3_lb_check_skb_data(). So fix this use-after-free by using skb_headlen() to dump skb->data instead of skb->len. Fixes: c39c4d98dc65 ("net: hns3: Add mac loopback selftest support in hns3 driver") Signed-off-by: Yonglong Liu <[email protected]> Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-06net: hns3: add a missing uninit debugfs when unload driverHuazhong Tan1-2/+1
When unloading driver, if flag HNS3_NIC_STATE_INITED has been already cleared, the debugfs will not be uninitialized, so fix it. Fixes: b2292360bb2a ("net: hns3: Add debugfs framework registration") Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-06net: hns3: fix for mishandle of asserting VF reset failHuazhong Tan1-0/+5
When asserts VF reset fail, flag HCLGEVF_STATE_CMD_DISABLE and handshake status should not set, otherwise the retry will fail. So adds a check for asserting VF reset and returns directly when fails. Fixes: ef5f8e507ec9 ("net: hns3: stop handling command queue while resetting VF") Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-06net: hns3: check reset pending after FLR prepareHuazhong Tan1-1/+1
If there is a PF reset pending before FLR prepare, FLR's preparatory work will not fail, but the FLR rebuild procedure will fail for this pending. So this PF reset pending should be handled in the FLR preparatory. Fixes: 8627bdedc435 ("net: hns3: refactor the precedure of PF FLR") Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-06Merge branch 'smsc95xx-fix-smsc95xx_bind'David S. Miller1-1/+8
Andre Edich says: ==================== smsc95xx: fix smsc95xx_bind The patchset fixes two problems in the function smsc95xx_bind: - return of false success - memory leak Changes in v2: - added "Fixes" tags to both patches ==================== Signed-off-by: David S. Miller <[email protected]>
2020-07-06smsc95xx: avoid memory leak in smsc95xx_bindAndre Edich1-1/+2
In a case where the ID_REV register read is failed, the memory for a private data structure has to be freed before returning error from the function smsc95xx_bind. Fixes: bbd9f9ee69242 ("smsc95xx: add wol support for more frame types") Signed-off-by: Andre Edich <[email protected]> Signed-off-by: Parthiban Veerasooran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-06smsc95xx: check return value of smsc95xx_resetAndre Edich1-0/+6
The return value of the function smsc95xx_reset() must be checked to avoid returning false success from the function smsc95xx_bind(). Fixes: 2f7ca802bdae2 ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver") Signed-off-by: Andre Edich <[email protected]> Signed-off-by: Parthiban Veerasooran <[email protected]> Signed-off-by: David S. Miller <[email protected]>