aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-08ARM: davinci: select CONFIG_RESET_CONTROLLERArnd Bergmann1-0/+1
Selecting RESET_CONTROLLER is actually required, otherwise we can get a link failure in the clock driver: drivers/clk/davinci/psc.o: In function `__davinci_psc_register_clocks': psc.c:(.text+0x9a0): undefined reference to `devm_reset_controller_register' drivers/clk/davinci/psc-da850.o: In function `da850_psc0_init': psc-da850.c:(.text+0x24): undefined reference to `reset_controller_add_lookup' Link: https://lore.kernel.org/r/[email protected] Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5") Cc: <[email protected]> # v5.4 Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Acked-by: Sekhar Nori <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2020-01-08Merge tag 'tpmdd-next-20200108' of git://git.infradead.org/users/jjs/linux-tpmddLinus Torvalds2-2/+2
Pull more tpmd fixes from Jarkko Sakkinen: "One critical regression fix (the faulty commit got merged in rc3, but also marked for stable)" * tag 'tpmdd-next-20200108' of git://git.infradead.org/users/jjs/linux-tpmdd: tpm: Handle negative priv->response_len in tpm_common_read()
2020-01-08btrfs: fix memory leak in qgroup accountingJohannes Thumshirn1-1/+5
When running xfstests on the current btrfs I get the following splat from kmemleak: unreferenced object 0xffff88821b2404e0 (size 32): comm "kworker/u4:7", pid 26663, jiffies 4295283698 (age 8.776s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 10 ff fd 26 82 88 ff ff ...........&.... 10 ff fd 26 82 88 ff ff 20 ff fd 26 82 88 ff ff ...&.... ..&.... backtrace: [<00000000f94fd43f>] ulist_alloc+0x25/0x60 [btrfs] [<00000000fd023d99>] btrfs_find_all_roots_safe+0x41/0x100 [btrfs] [<000000008f17bd32>] btrfs_find_all_roots+0x52/0x70 [btrfs] [<00000000b7660afb>] btrfs_qgroup_rescan_worker+0x343/0x680 [btrfs] [<0000000058e66778>] btrfs_work_helper+0xac/0x1e0 [btrfs] [<00000000f0188930>] process_one_work+0x1cf/0x350 [<00000000af5f2f8e>] worker_thread+0x28/0x3c0 [<00000000b55a1add>] kthread+0x109/0x120 [<00000000f88cbd17>] ret_from_fork+0x35/0x40 This corresponds to: (gdb) l *(btrfs_find_all_roots_safe+0x41) 0x8d7e1 is in btrfs_find_all_roots_safe (fs/btrfs/backref.c:1413). 1408 1409 tmp = ulist_alloc(GFP_NOFS); 1410 if (!tmp) 1411 return -ENOMEM; 1412 *roots = ulist_alloc(GFP_NOFS); 1413 if (!*roots) { 1414 ulist_free(tmp); 1415 return -ENOMEM; 1416 } 1417 Following the lifetime of the allocated 'roots' ulist, it gets freed again in btrfs_qgroup_account_extent(). But this does not happen if the function is called with the 'BTRFS_FS_QUOTA_ENABLED' flag cleared, then btrfs_qgroup_account_extent() does a short leave and directly returns. Instead of directly returning we should jump to the 'out_free' in order to free all resources as expected. CC: [email protected] # 4.14+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Johannes Thumshirn <[email protected]> [ add comment ] Signed-off-by: David Sterba <[email protected]>
2020-01-08usb: missing parentheses in USE_NEW_SCHEMEQi Zhou1-1/+1
According to bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") the kernel will try the old enumeration scheme first for high speed devices. This can happen when a high speed device is plugged in. But due to missing parentheses in the USE_NEW_SCHEME define, this logic can get messed up and the incorrect result happens. Acked-by: Alan Stern <[email protected]> Signed-off-by: Qi Zhou <[email protected]> Link: https://lore.kernel.org/r/ht4mtag8ZP-HKEhD0KkJhcFnVlOFV8N8eNjJVRD9pDkkLUNhmEo8_cL_sl7xy9mdajdH-T8J3TFQsjvoYQT61NFjQXy469Ed_BbBw_x4S1E=@protonmail.com [ fixup changelog text - gregkh] Cc: stable <[email protected]> Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-08usb: ohci-da8xx: ensure error return on variable error is setColin Ian King1-2/+6
Currently when an error occurs when calling devm_gpiod_get_optional or calling gpiod_to_irq it causes an uninitialized error return in variable 'error' to be returned. Fix this by ensuring the error variable is set from da8xx_ohci->oc_gpio and oc_irq. Thanks to Dan Carpenter for spotting the uninitialized error in the gpiod_to_irq failure case. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: d193abf1c913 ("usb: ohci-da8xx: add vbus and overcurrent gpios") Signed-off-by: Colin Ian King <[email protected]> Cc: stable <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-08usb: musb: Disable pullup at initPaul Cercueil1-0/+3
The pullup may be already enabled before the driver is initialized. This happens for instance on JZ4740. It has to be disabled at init time, as we cannot guarantee that a gadget driver will be bound to the UDC. Signed-off-by: Paul Cercueil <[email protected]> Suggested-by: Bin Liu <[email protected]> Cc: [email protected] Signed-off-by: Bin Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-08usb: musb: fix idling for suspend after disconnect interruptTony Lindgren1-0/+8
When disconnected as USB B-device, suspend interrupt should come before diconnect interrupt, because the DP/DM pins are shorter than the VBUS/GND pins on the USB connectors. But we sometimes get a suspend interrupt after disconnect interrupt. In that case we have devctl set to 99 with VBUS still valid and musb_pm_runtime_check_session() wrongly thinks we have an active session. We have no other interrupts after disconnect coming in this case at least with the omap2430 glue. Let's fix the issue by checking the interrupt status again with delayed work for the devctl 99 case. In the suspend after disconnect case the devctl session bit has cleared by then and musb can idle. For a typical USB B-device connect case we just continue with normal interrupts. Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") Cc: Merlijn Wajer <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Sebastian Reichel <[email protected]> Cc: [email protected] Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Bin Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-08usb: typec: ucsi: Fix the notification bit offsetsHeikki Krogerus1-9/+9
The bit offsets for the Set Notification Enable command were not considering the reserved bits in the middle. Fixes: 470ce43a1a81 ("usb: typec: ucsi: Remove struct ucsi_control") Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-08tpm: Handle negative priv->response_len in tpm_common_read()Tadeusz Struk2-2/+2
The priv->response_length can hold the size of an response or an negative error code, and the tpm_common_read() needs to handle both cases correctly. Changed the type of response_length to signed and accounted for negative value in tpm_common_read(). Cc: [email protected] Fixes: d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode") Reported-by: Laura Abbott <[email protected]> Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-01-08btrfs: do not delete mismatched root refsJosef Bacik1-4/+6
btrfs_del_root_ref() will simply WARN_ON() if the ref doesn't match in any way, and then continue to delete the reference. This shouldn't happen, we have these values because there's more to the reference than the original root and the sub root. If any of these checks fail, return -ENOENT. CC: [email protected] # 4.4+ Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-08btrfs: fix invalid removal of root refJosef Bacik1-8/+19
If we have the following sequence of events btrfs sub create A btrfs sub create A/B btrfs sub snap A C mkdir C/foo mv A/B C/foo rm -rf * We will end up with a transaction abort. The reason for this is because we create a root ref for B pointing to A. When we create a snapshot of C we still have B in our tree, but because the root ref points to A and not C we will make it appear to be empty. The problem happens when we move B into C. This removes the root ref for B pointing to A and adds a ref of B pointing to C. When we rmdir C we'll see that we have a ref to our root and remove the root ref, despite not actually matching our reference name. Now btrfs_del_root_ref() allowing this to work is a bug as well, however we know that this inode does not actually point to a root ref in the first place, so we shouldn't be calling btrfs_del_root_ref() in the first place and instead simply look up our dir index for this item and do the rest of the removal. CC: [email protected] # 4.4+ Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-08btrfs: rework arguments of btrfs_unlink_subvolJosef Bacik1-26/+20
btrfs_unlink_subvol takes the name of the dentry and the root objectid based on what kind of inode this is, either a real subvolume link or a empty one that we inherited as a snapshot. We need to fix how we unlink in the case for BTRFS_EMPTY_SUBVOL_DIR_OBJECTID in the future, so rework btrfs_unlink_subvol to just take the dentry and handle getting the right objectid given the type of inode this is. There is no functional change here, simply pushing the work into btrfs_unlink_subvol() proper. Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-08ALSA: hda/realtek - Add quirk for the bass speaker on Lenovo Yoga X1 7th genKailang Yang1-0/+1
Add quirk to ALC285_FIXUP_SPEAKER2_TO_DAC1, which is the same fixup applied for X1 Carbon 7th gen in commit d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen"). Signed-off-by: Kailang Yang <[email protected]> Reviewed-by: Jaroslav Kysela <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2020-01-08ALSA: hda/realtek - Set EAPD control to default for ALC222Kailang Yang1-0/+1
Set EAPD control to verb control. Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2020-01-08ARM: dts: aspeed: rainier: Fix fan fault and presenceBrandon Wyman1-2/+2
The PCA9552 used for fan fault and presence information is at address 61h, not 60h. Fixes: 2efc118ce3c3 ("ARM: dts: aspeed: rainier: Add i2c devices") Signed-off-by: Brandon Wyman <[email protected]> Reviewed-by: Eddie James <[email protected]> Signed-off-by: Joel Stanley <[email protected]>
2020-01-08ARM: dts: aspeed: rainier: Remove duplicate i2c bussesJoel Stanley1-365/+0
This is a revert of "ARM: dts: aspeed: rainier: Add i2c devices", which was already applied to the tree. Fixes: 9c44db7096e0 ("ARM: dts: aspeed: rainier: Add i2c devices") Reviewed-by: Jim Wright <[email protected]> Tested-by: Jim Wright <[email protected]> Signed-off-by: Joel Stanley <[email protected]>
2020-01-08ARM: dts: aspeed: tacoma: Remove duplicate flash nodesJoel Stanley1-31/+0
This is a revert of "ARM: dts: aspeed: tacoma: Enable FMC and SPI devices" which was already applied as part of "ARM: dts: aspeed: Add Tacoma machine". Fixes: 8737481e381c ("ARM: dts: aspeed: tacoma: Enable FMC and SPI devices") Reviewed-by: Andrew Jeffery <[email protected]> Signed-off-by: Joel Stanley <[email protected]>
2020-01-08ARM: dts: aspeed: tacoma: Remove duplicate i2c bussesJoel Stanley1-367/+0
This is a revert of "ARM: dts: aspeed: tacoma: Enable I2C busses", which was already applied as part of "ARM: dts: aspeed: Add Tacoma machine". Fixes: 606bcdde6724 ("ARM: dts: aspeed: tacoma: Enable I2C busses") Reviewed-by: Andrew Jeffery <[email protected]> Signed-off-by: Joel Stanley <[email protected]>
2020-01-08ARM: dts: aspeed: tacoma: Fix fsi master nodeJoel Stanley1-0/+5
This was broken when applying "ARM: dts: aspeed: tacoma: Add host FSI description". Fixes: a981c93300ef ("ARM: dts: aspeed: tacoma: Add host FSI description") Acked-by: Andrew Jeffery <[email protected]> Signed-off-by: Joel Stanley <[email protected]>
2020-01-08ARM: dts: aspeed-g6: Fix FSI master locationJoel Stanley1-20/+19
The FIS nodes were placed incorrectly in the device tree. Fixes: 0fe4e304782c ("ARM: dts: aspeed-g6: Describe FSI masters") Reviewed-by: Andrew Jeffery <[email protected]> Signed-off-by: Joel Stanley <[email protected]>
2020-01-07ASoC: Fix NULL dereference at freeingTakashi Iwai1-0/+3
When an ASoC driver with pcm_destruct component ops is freed before the PCM object instantiation (e.g. deferring the probe), it hits an Oops at snd_soc_pcm_component_free() that calls the pcm_destruct ops unconditionally. Fix it by adding a NULL-check of rtd->pcm before calling callbacks. Fixes: c64bfc906600 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Reported-by: Matthias Brugger <[email protected]> Tested-by: Ben Ho <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-07net: usb: lan78xx: fix possible skb leakEric Dumazet1-6/+3
If skb_linearize() fails, we need to free the skb. TSO makes skb bigger, and this bug might be the reason Raspberry Pi 3B+ users had to disable TSO. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: RENARD Pierre-Francois <[email protected]> Cc: Stefan Wahren <[email protected]> Cc: Woojung Huh <[email protected]> Cc: Microchip Linux Driver Support <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-07net: stmmac: Fixed link does not need MDIO BusJose Abreu1-1/+1
When using fixed link we don't need the MDIO bus support. Reported-by: Heiko Stuebner <[email protected]> Reported-by: kernelci.org bot <[email protected]> Fixes: d3e014ec7d5e ("net: stmmac: platform: Fix MDIO init for platforms without PHY") Signed-off-by: Jose Abreu <[email protected]> Acked-by: Sriram Dash <[email protected]> Tested-by: Patrice Chotard <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Acked-by: Neil Armstrong <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Tested-by: Florian Fainelli <f.fainelli@gmail> # Lamobo R1 (fixed-link + MDIO sub node for roboswitch). Signed-off-by: David S. Miller <[email protected]>
2020-01-07Merge branch 'vlan-rtnetlink-newlink-fixes'David S. Miller3-8/+15
Eric Dumazet says: ==================== vlan: rtnetlink newlink fixes First patch fixes a potential memory leak found by syzbot Second patch makes vlan_changelink() aware of errors and report them to user. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-07vlan: vlan_changelink() should propagate errorsEric Dumazet1-3/+7
Both vlan_dev_change_flags() and vlan_dev_set_egress_priority() can return an error. vlan_changelink() should not ignore them. Fixes: 07b5b17e157b ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-07vlan: fix memory leak in vlan_dev_set_egress_priorityEric Dumazet3-5/+8
There are few cases where the ndo_uninit() handler might be not called if an error happens while device is initialized. Since vlan_newlink() calls vlan_changelink() before trying to register the netdevice, we need to make sure vlan_dev_uninit() has been called at least once, or we might leak allocated memory. BUG: memory leak unreferenced object 0xffff888122a206c0 (size 32): comm "syz-executor511", pid 7124, jiffies 4294950399 (age 32.240s) hex dump (first 32 bytes): 00 00 00 00 00 00 61 73 00 00 00 00 00 00 00 00 ......as........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000eb3bb85>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<000000000eb3bb85>] slab_post_alloc_hook mm/slab.h:586 [inline] [<000000000eb3bb85>] slab_alloc mm/slab.c:3320 [inline] [<000000000eb3bb85>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3549 [<000000007b99f620>] kmalloc include/linux/slab.h:556 [inline] [<000000007b99f620>] vlan_dev_set_egress_priority+0xcc/0x150 net/8021q/vlan_dev.c:194 [<000000007b0cb745>] vlan_changelink+0xd6/0x140 net/8021q/vlan_netlink.c:126 [<0000000065aba83a>] vlan_newlink+0x135/0x200 net/8021q/vlan_netlink.c:181 [<00000000fb5dd7a2>] __rtnl_newlink+0x89a/0xb80 net/core/rtnetlink.c:3305 [<00000000ae4273a1>] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3363 [<00000000decab39f>] rtnetlink_rcv_msg+0x178/0x4b0 net/core/rtnetlink.c:5424 [<00000000accba4ee>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2477 [<00000000319fe20f>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 [<00000000d51938dc>] netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] [<00000000d51938dc>] netlink_unicast+0x223/0x310 net/netlink/af_netlink.c:1328 [<00000000e539ac79>] netlink_sendmsg+0x2c0/0x570 net/netlink/af_netlink.c:1917 [<000000006250c27e>] sock_sendmsg_nosec net/socket.c:639 [inline] [<000000006250c27e>] sock_sendmsg+0x54/0x70 net/socket.c:659 [<00000000e2a156d1>] ____sys_sendmsg+0x2d0/0x300 net/socket.c:2330 [<000000008c87466e>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2384 [<00000000110e3054>] __sys_sendmsg+0x80/0xf0 net/socket.c:2417 [<00000000d71077c8>] __do_sys_sendmsg net/socket.c:2426 [inline] [<00000000d71077c8>] __se_sys_sendmsg net/socket.c:2424 [inline] [<00000000d71077c8>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2424 Fixe: 07b5b17e157b ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller2-4/+16
Daniel Borkmann says: ==================== pull-request: bpf 2020-01-07 The following pull-request contains BPF updates for your *net* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 2 files changed, 16 insertions(+), 4 deletions(-). The main changes are: 1) Fix a use-after-free in cgroup BPF due to auto-detachment, from Roman Gushchin. 2) Fix skb out-of-bounds access in ld_abs/ind instruction, from Daniel Borkmann. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-07stmmac: debugfs entry name is not be changed when udev rename device name.Jiping Ma1-0/+32
Add one notifier for udev changes net device name. Fixes: b6601323ef9e ("net: stmmac: debugfs entry name is not be changed when udev rename") Signed-off-by: Jiping Ma <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-07io_uring: remove punt of short reads to async contextJens Axboe1-12/+0
We currently punt any short read on a regular file to async context, but this fails if the short read is due to running into EOF. This is especially problematic since we only do the single prep for commands now, as we don't reset kiocb->ki_pos. This can result in a 4k read on a 1k file returning zero, as we detect the short read and then retry from async context. At the time of retry, the position is now 1k, and we end up reading nothing, and hence return 0. Instead of trying to patch around the fact that short reads can be legitimate and won't succeed in case of retry, remove the logic to punt a short read to async context. Simply return it. Signed-off-by: Jens Axboe <[email protected]>
2020-01-07Merge tag 'omap-for-v5.5/fixes-rc5' of ↵Olof Johansson6-18/+37
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Fixes for omaps for v5.5-rc cycle Here are few fixes for v5.5-rc cycle: - Two corner case fixes related to ti-sysc driver clock issues - Fixes for am57xx dts for pcie gpios - Beagle-x15 regulator dts fix - Fix for wkup_m3_ipc driver race * tag 'omap-for-v5.5/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: soc: ti: wkup_m3_ipc: Fix race condition with rproc_boot ARM: dts: beagle-x15-common: Model 5V0 regulator ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes bus: ti-sysc: Fix iterating over clocks ARM: OMAP2+: Fix ti_sysc_find_one_clockdomain to check for to_clk_hw_omap Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Olof Johansson <[email protected]>
2020-01-07i40iw: Remove setting of VMA private data and use rdma_user_mmap_ioShiraz Saleem1-8/+6
vm_ops is now initialized in ib_uverbs_mmap() with the recent rdma mmap API changes. Earlier it was done in rdma_umap_priv_init() which would not be called unless a driver called rdma_user_mmap_io() in its mmap. i40iw does not use the rdma_user_mmap_io API but sets the vma's vm_private_data to a driver object. This now conflicts with the vm_op rdma_umap_close as priv pointer points to the i40iw driver object instead of the private data setup by core when rdma_user_mmap_io is called. This leads to a crash in rdma_umap_close with a mmap put being called when it should not have. Remove the redundant setting of the vma private_data in i40iw as it is not used. Also move i40iw over to use the rdma_user_mmap_io API. This gives the extra protection of having the mappings zapped when the context is detsroyed. BUG: unable to handle page fault for address: 0000000100000001 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP PTI CPU: 6 PID: 9528 Comm: rping Kdump: loaded Not tainted 5.5.0-rc4+ #117 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Q87M-D2H, BIOS F7 01/17/2014 RIP: 0010:rdma_user_mmap_entry_put+0xa/0x30 [ib_core] RSP: 0018:ffffb340c04c7c38 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ffff9308e7be2a00 RCX: 000000000000cec0 RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000100000001 RBP: ffff9308dc7641f0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff8d4414d8 R12: ffff93075182c780 R13: 0000000000000001 R14: ffff93075182d2a8 R15: ffff9308e2ddc840 FS: 0000000000000000(0000) GS:ffff9308fdc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000100000001 CR3: 00000002e0412004 CR4: 00000000001606e0 Call Trace: rdma_umap_close+0x40/0x90 [ib_uverbs] remove_vma+0x43/0x80 exit_mmap+0xfd/0x1b0 mmput+0x6e/0x130 do_exit+0x290/0xcc0 ? get_signal+0x152/0xc40 do_group_exit+0x46/0xc0 get_signal+0x1bd/0xc40 ? prepare_to_wait_event+0x97/0x190 do_signal+0x36/0x630 ? remove_wait_queue+0x60/0x60 ? __audit_syscall_exit+0x1d9/0x290 ? rcu_read_lock_sched_held+0x52/0x90 ? kfree+0x21c/0x2e0 exit_to_usermode_loop+0x4f/0xc3 do_syscall_64+0x1ed/0x270 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fae715a81fd Code: Bad RIP value. RSP: 002b:00007fae6e163cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: fffffffffffffe00 RBX: 00007fae6e163d30 RCX: 00007fae715a81fd RDX: 0000000000000010 RSI: 00007fae6e163cf0 RDI: 0000000000000003 RBP: 00000000013413a0 R08: 00007fae68000000 R09: 0000000000000017 R10: 0000000000000001 R11: 0000000000000293 R12: 00007fae680008c0 R13: 00007fae6e163cf0 R14: 00007fae717c9804 R15: 00007fae6e163ed0 CR2: 0000000100000001 ---[ end trace b33d58d3a06782cb ]--- RIP: 0010:rdma_user_mmap_entry_put+0xa/0x30 [ib_core] Fixes: b86deba977a9 ("RDMA/core: Move core content from ib_uverbs to ib_core") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpuChunming Zhou1-1/+2
Can expose it now that the khronos has exposed the vlk extension. Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Flora Cui <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-01-07drm/amd/display: Reduce HDMI pixel encoding if max clock is exceededThomas Anderson1-22/+23
For high-res (8K) or HFR (4K120) displays, using uncompressed pixel formats like YCbCr444 would exceed the bandwidth of HDMI 2.0, so the "interesting" modes would be disabled, leaving only low-res or low framerate modes. This change lowers the pixel encoding to 4:2:2 or 4:2:0 if the max TMDS clock is exceeded. Verified that 8K30 and 4K120 are now available and working with a Samsung Q900R over an HDMI 2.0b link from a Radeon 5700. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Thomas Anderson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-01-07Revert "drm/amdgpu: Set no-retry as default."Alex Deucher1-2/+2
This reverts commit 51bfac71cade386966791a8db87a5912781d249f. This causes stability issues on some raven boards. Revert for now until a proper fix is completed. Bug: https://gitlab.freedesktop.org/drm/amd/issues/934 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206017 Reviewed-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-01-07iommu/dma: fix variable 'cookie' set but not usedQian Cai1-3/+0
The commit c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()") introduced a compliation warning, drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi': drivers/iommu/dma-iommu.c:1206:27: warning: variable 'cookie' set but not used [-Wunused-but-set-variable] struct iommu_dma_cookie *cookie; ^~~~~~ Fixes: c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()") Signed-off-by: Qian Cai <[email protected]> Acked-by: Robin Murphy <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07iommu/vt-d: Unlink device if failed to add to groupJon Derrick1-3/+10
If the device fails to be added to the group, make sure to unlink the reference before returning. Signed-off-by: Jon Derrick <[email protected]> Fixes: 39ab9555c2411 ("iommu: Add sysfs bindings for struct iommu_device") Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07iommu: Remove device link to group on failureJon Derrick1-0/+1
This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by: Jon Derrick <[email protected]> Fixes: 797a8b4d768c5 ("iommu: Handle default domain attach failure") Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07iommu/vt-d: Fix adding non-PCI devices to Intel IOMMUPatrick Steinhardt1-1/+8
Starting with commit fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices"), we now probe DMA-capable ACPI name space devices. On Dell XPS 13 9343, which has an Intel LPSS platform device INTL9C60 enumerated via ACPI, this change leads to the following warning: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at pci_device_group+0x11a/0x130 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 5.5.0-rc3+ #22 Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A20 06/06/2019 RIP: 0010:pci_device_group+0x11a/0x130 Code: f0 ff ff 48 85 c0 49 89 c4 75 c4 48 8d 74 24 10 48 89 ef e8 48 ef ff ff 48 85 c0 49 89 c4 75 af e8 db f7 ff ff 49 89 c4 eb a5 <0f> 0b 49 c7 c4 ea ff ff ff eb 9a e8 96 1e c7 ff 66 0f 1f 44 00 00 RSP: 0000:ffffc0d6c0043cb0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffffa3d1d43dd810 RCX: 0000000000000000 RDX: ffffa3d1d4fecf80 RSI: ffffa3d12943dcc0 RDI: ffffa3d1d43dd810 RBP: ffffa3d1d43dd810 R08: 0000000000000000 R09: ffffa3d1d4c04a80 R10: ffffa3d1d4c00880 R11: ffffa3d1d44ba000 R12: 0000000000000000 R13: ffffa3d1d4383b80 R14: ffffa3d1d4c090d0 R15: ffffa3d1d4324530 FS: 0000000000000000(0000) GS:ffffa3d1d6700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000460a001 CR4: 00000000003606e0 Call Trace: ? iommu_group_get_for_dev+0x81/0x1f0 ? intel_iommu_add_device+0x61/0x170 ? iommu_probe_device+0x43/0xd0 ? intel_iommu_init+0x1fa2/0x2235 ? pci_iommu_init+0x52/0xe7 ? e820__memblock_setup+0x15c/0x15c ? do_one_initcall+0xcc/0x27e ? kernel_init_freeable+0x169/0x259 ? rest_init+0x95/0x95 ? kernel_init+0x5/0xeb ? ret_from_fork+0x35/0x40 ---[ end trace 28473e7abc25b92c ]--- DMAR: ACPI name space devices didn't probe correctly The bug results from the fact that while we now enumerate ACPI devices, we aren't able to handle any non-PCI device when generating the device group. Fix the issue by implementing an Intel-specific callback that returns `pci_device_group` only if the device is a PCI device. Otherwise, it will return a generic device group. Fixes: fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices") Signed-off-by: Patrick Steinhardt <[email protected]> Cc: [email protected] # v5.3+ Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07drm/fb-helper: Round up bits_per_pixel if possibleGeert Uytterhoeven1-1/+6
When userspace requests a video mode parameter value that is not supported, frame buffer device drivers should round it up to a supported value, if possible, instead of just rejecting it. This allows applications to quickly scan for supported video modes. Currently this rule is not followed for the number of bits per pixel, causing e.g. "fbset -depth N" to fail, if N is smaller than the current number of bits per pixel. Fix this by returning an error only if bits per pixel is too large, and setting it to the current value otherwise. See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View of /dev/fb*"). Fixes: 865afb11949e5bf4 ("drm/fb-helper: reject any changes to the fbdev") Cc: [email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/sun4i: tcon: Set RGB DCLK min. divider based on hardware modelChen-Yu Tsai2-3/+13
In commit 0b8e7bbde5e7 ("drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.") it was assumed that all TCON variants support a minimum divider of 1 if only DCLK was used. However, the oldest generation of hardware only supports minimum divider of 4 if only DCLK is used. If a divider of 1 was used on this old hardware, some scrolling artifact would appear. A divider of 2 seemed OK, but a divider of 3 had artifacts as well. Set the minimum divider when outputing to parallel RGB based on the hardware model, with a minimum of 4 for the oldest (A10/A10s/A13/A20) hardware, and a minimum of 1 for the rest. A value is not set for the TCON variants lacking channel 0. This fixes the scrolling artifacts seen on my A13 tablet. Fixes: 0b8e7bbde5e7 ("drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.") Cc: <[email protected]> # 5.4.x Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/dp: Disable Port sync mode correctly on teardownManasi Navare1-6/+1
While clearing the Ports ync mode enable and master select bits we need to clear the register completely instead of using disable masks v3: * Remove reg variable (Matt) v2: * Just write 0 to the reg (Ville) * Rebase Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/5 Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Fixes: 51528afe7c5e ("drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence") Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a3d9382bd439e7be1858abc3d5f014dd55913448) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915: Add Wa_1407352427:icl,ehlMatt Roper2-0/+7
The workaround database now indicates we need to disable psdunit clock gating as well. v3: - Rebase on top of other workarounds that have landed. - Restrict cc:stable tag to 5.2+ since that's when ICL was first officially supported. Bspec: 32354 Bspec: 33450 Bspec: 33451 Suggested-by: Lionel Landwerlin <[email protected]> Cc: [email protected] # v5.2+ Cc: Lionel Landwerlin <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Matt Atwood <[email protected]> Signed-off-by: Matt Roper <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1cd21a7c5679015352e8a6f46813aced51d71bb8) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915: Add Wa_1408615072 and Wa_1407596294 to icl,ehlMatt Roper2-1/+11
Workaround database indicates we should disable clock gating of both the vsunit and hsunit. Bspec: 33450 Bspec: 33451 Cc: [email protected] Cc: Lucas De Marchi <[email protected]> Cc: Matt Atwood <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lucas De Marchi <[email protected]> (cherry picked from commit b9cf9dac3dac4c1d2a47d34f30ec53c0423cecf8) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915/gt: Restore coarse power gatingChris Wilson1-2/+4
The coarse power gating was disabled as part of commit 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") as a prelude to recover from the context corruption; the power gating itself has no direct impact on the RC6 context corruption. However, that recovery scheme was never implemented due to difficult corner cases, and so we no longer need to keep the power gating disabled. Fixes: 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") Closes: https://gitlab.freedesktop.org/drm/intel/issues/846 Signed-off-by: Chris Wilson <[email protected]> Cc: Imre Deak <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: Jon Bloomfield <[email protected]> Reviewed-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 32f408ac3e5d95781f52328a09e5409b01255841) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915/gt: Do not restore invalid RS stateChris Wilson1-20/+11
Only restore valid resource streamer state from the context image, i.e. avoid restoring if we know the image is invalid. Closes: https://gitlab.freedesktop.org/drm/intel/issues/446 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: [email protected] (cherry picked from commit ecfcd2da335816516dc27434a65899a77886d80a) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07um: Implement copy_thread_tlsAmanieu d'Antras5-12/+10
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07clone3: ensure copy_thread_tls is implementedAmanieu d'Antras1-0/+10
copy_thread implementations handle CLONE_SETTLS by reading the TLS value from the registers containing the syscall arguments for clone. This doesn't work with clone3 since the TLS value is passed in clone_args instead. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07xtensa: Implement copy_thread_tlsAmanieu d'Antras2-4/+5
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07riscv: Implement copy_thread_tlsAmanieu d'Antras2-3/+4
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07parisc: Implement copy_thread_tlsAmanieu d'Antras2-4/+5
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.