summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-07-21qed: suppress false-positives interrupt error messages on HW initAlexander Lobakin
It was found that qed_pglueb_rbc_attn_handler() can produce a lot of false-positive error detections on driver load/reload (especially after crashes/recoveries) and spam the kernel log: [ 4.958275] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d00ff0 [ 2079.146764] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0 [ 2116.374631] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0 [ 2135.250564] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0 [...] Reduce the logging level of two false-positive prone error messages from notice to verbose on initialization (only) to not mix it with real error attentions while debugging. Fixes: 666db4862f2d ("qed: Revise load sequence to avoid PCI errors") Signed-off-by: Alexander Lobakin <alobakin@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21qed: suppress "don't support RoCE & iWARP" flooding on HW initAlexander Lobakin
Change the verbosity of the "don't support RoCE & iWARP simultaneously" warning to debug level to stop flooding on driver/hardware initialization: [ 4.783230] qede 01:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth0] [ 4.810020] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 4.861186] qede 01:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth1] [ 4.893311] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 5.181713] qede a1:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth2] [ 5.224740] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 5.276449] qede a1:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth3] [ 5.318671] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only [ 5.369548] qede a1:00.02: Storm FW 8.37.7.0, Management FW 8.52.9.0 [MBI 15.10.6] [eth4] [ 5.411645] [qed_rdma_set_pf_params:2076()]Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only Fixes: e0a8f9de16fc ("qed: Add iWARP enablement support") Signed-off-by: Alexander Lobakin <alobakin@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21netdevsim: fix unbalaced locking in nsim_create()Taehee Yoo
In the nsim_create(), rtnl_lock() is called before nsim_bpf_init(). If nsim_bpf_init() is failed, rtnl_unlock() should be called, but it isn't called. So, unbalanced locking would occur. Fixes: e05b2d141fef ("netdevsim: move netdev creation/destruction to dev probe") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: dsa: microchip: call phy_remove_link_mode during probeHelmut Grohne
When doing "ip link set dev ... up" for a ksz9477 backed link, ksz9477_phy_setup is called and it calls phy_remove_link_mode to remove 1000baseT HDX. During phy_remove_link_mode, phy_advertise_supported is called. Doing so reverts any previous change to advertised link modes e.g. using a udevd .link file. phy_remove_link_mode is not meant to be used while opening a link and should be called during phy probe when the link is not yet available to userspace. Therefore move the phy_remove_link_mode calls into ksz9477_switch_register. It indirectly calls dsa_register_switch, which creates the relevant struct phy_devices and we update the link modes right after that. At that time dev->features is already initialized by ksz9477_switch_detect. Remove phy_setup from ksz_dev_ops as no users remain. Link: https://lore.kernel.org/netdev/20200715192722.GD1256692@lunn.ch/ Fixes: 42fc6a4c613019 ("net: dsa: microchip: prepare PHY for proper advertisement") Signed-off-by: Helmut Grohne <helmut.grohne@intenta.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix return value error when query MAC link status failJian Shen
Currently, PF queries the MAC link status per second by calling function hclge_get_mac_link_status(). It return the error code when failed to send cmdq command to firmware. It's incorrect, because this return value is used as the MAC link status, which 0 means link down, and none-zero means link up. So fixes it. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix error handling for desc fillingYunsheng Lin
The content of the TX desc is automatically cleared by the HW when the HW has sent out the packet to the wire. When desc filling fails in hns3_nic_net_xmit(), it will call hns3_clear_desc() to do the error handling, which miss zeroing of the TX desc and the checking if a unmapping is needed. So add the zeroing and checking in hns3_clear_desc() to avoid the above problem. Also add DESC_TYPE_UNKNOWN to indicate the info in desc_cb is not valid, because hns3_nic_reclaim_desc() may treat the desc_cb->type of zero as packet and add to the sent pkt statistics accordingly. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix for not calculating TX BD send size correctlyYunsheng Lin
With GRO and fraglist support, the SKB can be aggregated to a total size of 65535, and when that SKB is forwarded through a bridge, the size of the SKB may be pushed to exceed the size of 65535 when br_dev_queue_push_xmit() is called. The max send size of BD supported by the HW is 65535, when a SKB with a headlen of over 65535 is sent to the driver, the driver needs to use multi BD to send the linear data, and the send size of the last BD is calculated incorrectly by the driver who is using '&' operation, which causes a TX error. Use '%' operation to fix this problem. Fixes: 3fe13ed95dd3 ("net: hns3: avoid mult + div op in critical data path") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: hns3: fix for not unmapping TX buffer correctlyYunsheng Lin
When a big TX buffer is sent using multi BD, the driver maps the whole TX buffer, and unmaps it using info in desc_cb corresponding to each BD, but only the info in the desc_cb of first BD is correct, other info in desc_cb is wrong, which causes TX unmapping problem when SMMU is on. Only set the mapping and freeing info in the desc_cb of first BD to fix this problem, because the TX buffer only need to be unmapped and freed once. Fixes: 1e8a7977d09f("net: hns3: add handling for big TX fragment") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huzhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21net: ethernet: ravb: exit if re-initialization fails in tx timeoutYoshihiro Shimoda
According to the report of [1], this driver is possible to cause the following error in ravb_tx_timeout_work(). ravb e6800000.ethernet ethernet: failed to switch device to config mode This error means that the hardware could not change the state from "Operation" to "Configuration" while some tx and/or rx queue are operating. After that, ravb_config() in ravb_dmac_init() will fail, and then any descriptors will be not allocaled anymore so that NULL pointer dereference happens after that on ravb_start_xmit(). To fix the issue, the ravb_tx_timeout_work() should check the return values of ravb_stop_dma() and ravb_dmac_init(). If ravb_stop_dma() fails, ravb_tx_timeout_work() re-enables TX and RX and just exits. If ravb_dmac_init() fails, just exits. [1] https://lore.kernel.org/linux-renesas-soc/20200518045452.2390-1-dirk.behme@de.bosch.com/ Reported-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-21drm/amdgpu: Fix NULL dereference in dpm sysfs handlersPaweł Gronowski
NULL dereference occurs when string that is not ended with space or newline is written to some dpm sysfs interface (for example pp_dpm_sclk). This happens because strsep replaces the tmp with NULL if the delimiter is not present in string, which is then dereferenced by tmp[0]. Reproduction example: sudo sh -c 'echo -n 1 > /sys/class/drm/card0/device/pp_dpm_sclk' Signed-off-by: Paweł Gronowski <me@woland.xyz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-07-21drm/amd/powerplay: fix a crash when overclocking Vega MQiu Wenbo
Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and vddci_voltage_table is empty. It has been tested on Intel Hades Canyon (i7-8809G). Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208489 Fixes: ac7822b0026f ("drm/amd/powerplay: add smumgr support for VEGAM (v2)") Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Qiu Wenbo <qiuwenbo@phytium.com.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-07-21serial: 8250_mtk: Fix high-speed baud rates clampingSerge Semin
Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") fixed limits of a baud rate setting for a generic 8250 port. In other words since that commit the baud rate has been permitted to be within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely normal for a standard 8250 UART port. But there are custom 8250 ports, which provide extended baud rate limits. In particular the Mediatek 8250 port can work with baud rates up to "uartclk" speed. Normally that and any other peculiarity is supposed to be handled in a custom set_termios() callback implemented in the vendor-specific 8250-port glue-driver. Currently that is how it's done for the most of the vendor-specific 8250 ports, but for some reason for Mediatek a solution has been spread out to both the glue-driver and to the generic 8250-port code. Due to that a bug has been introduced, which permitted the extended baud rate limit for all even for standard 8250-ports. The bug has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") by narrowing the baud rates limit back down to the normal bounds. Unfortunately by doing so we also broke the Mediatek-specific extended bauds feature. A fix of the problem described above is twofold. First since we can't get back the extended baud rate limits feature to the generic set_termios() function and that method supports only a standard baud rates range, the requested baud rate must be locally stored before calling it and then restored back to the new termios structure after the generic set_termios() finished its magic business. By doing so we still use the serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers, while the extended baud rate setting procedure will be performed later in the custom Mediatek-specific set_termios() callback. Second since a true baud rate is now fully calculated in the custom set_termios() method we need to locally update the port timeout by calling the uart_update_timeout() function. After the fixes described above are implemented in the 8250_mtk.c driver, the Mediatek 8250-port should get back to normally working with extended baud rates. Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") Reported-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: stable <stable@vger.kernel.org> Tested-by: Claire Chang <tientzu@chromium.org> Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21serial: 8250: fix null-ptr-deref in serial8250_start_tx()Yang Yingliang
I got null-ptr-deref in serial8250_start_tx(): [ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 78.123778] Mem abort info: [ 78.126560] ESR = 0x86000007 [ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits [ 78.134891] SET = 0, FnV = 0 [ 78.137933] EA = 0, S1PTW = 0 [ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600 [ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000 [ 78.160029] Internal error: Oops: 86000007 [#1] SMP [ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd [ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48 [ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020 [ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [ 78.228435] pc : 0x0 [ 78.230618] lr : serial8250_start_tx+0x160/0x260 [ 78.235215] sp : ffff800062eefb80 [ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff [ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000 [ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000 [ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002 [ 78.259679] x21: 0000000000000001 x20: 0000000000000000 [ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000 [ 78.270259] x17: 0000000000000000 x16: 0000000000000000 [ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6 [ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539 [ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0 [ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88 [ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000 [ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8 [ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002 [ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8 [ 78.317873] Call trace: [ 78.320312] 0x0 [ 78.322147] __uart_start.isra.9+0x64/0x78 [ 78.326229] uart_start+0xb8/0x1c8 [ 78.329620] uart_flush_chars+0x24/0x30 [ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30 [ 78.338128] n_tty_receive_buf+0x44/0x2c8 [ 78.342122] tty_ioctl+0x348/0x11f8 [ 78.345599] ksys_ioctl+0xd8/0xf8 [ 78.348903] __arm64_sys_ioctl+0x2c/0xc8 [ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0 [ 78.357583] do_el0_svc+0x44/0xd0 [ 78.360887] el0_sync_handler+0x14c/0x1d0 [ 78.364880] el0_sync+0x140/0x180 [ 78.368185] Code: bad PC value SERIAL_PORT_DFNS is not defined on each arch, if it's not defined, serial8250_set_defaults() won't be called in serial8250_isa_init_ports(), so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref. Fix this problem by calling serial8250_set_defaults() after init uart port. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21serial: tegra: drop bogus NULL tty-port checksJohan Hovold
The struct tty_port is part of the uart state and will never be NULL in the receive helpers. Drop the bogus NULL checks and rename the pointer-variables "port" to differentiate them from struct tty_struct pointers (which can be NULL). Fixes: 962963e4ee23 ("serial: tegra: Switch to using struct tty_port") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200710135947.2737-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21serial: tegra: fix CREAD handling for PIOJohan Hovold
Commit 33ae787b74fc ("serial: tegra: add support to ignore read") added support for dropping input in case CREAD isn't set, but for PIO the ignore_status_mask wasn't checked until after the character had been put in the receive buffer. Note that the NULL tty-port test is bogus and will be removed by a follow-on patch. Fixes: 33ae787b74fc ("serial: tegra: add support to ignore read") Cc: stable <stable@vger.kernel.org> # 5.4 Cc: Shardar Shariff Md <smohammed@nvidia.com> Cc: Krishna Yarlagadda <kyarlagadda@nvidia.com> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200710135947.2737-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21RDMA/mlx5: Prevent prefetch from racing with implicit destructionJason Gunthorpe
Prefetch work in mlx5_ib_prefetch_mr_work can be queued and able to run concurrently with destruction of the implicit MR. The num_deferred_work was intended to serialize this, but there is a race: CPU0 CPU1 mlx5_ib_free_implicit_mr() xa_erase(odp_mkeys) synchronize_srcu() __xa_erase(implicit_children) mlx5_ib_prefetch_mr_work() pagefault_mr() pagefault_implicit_mr() implicit_get_child_mr() xa_cmpxchg() atomic_dec_and_test(num_deferred_mr) wait_event(imr->q_deferred_work) ib_umem_odp_release(odp_imr) kfree(odp_imr) At this point in mlx5_ib_free_implicit_mr() the implicit_children list is supposed to be empty forever so that destroy_unused_implicit_child_mr() and related are not and will not be running. Since it is not empty the destroy_unused_implicit_child_mr() flow ends up touching deallocated memory as mlx5_ib_free_implicit_mr() already tore down the imr parent. The solution is to flush out the prefetch wq by driving num_deferred_work to zero after creation of new prefetch work is blocked. Fixes: 5256edcb98a1 ("RDMA/mlx5: Rework implicit ODP destroy") Link: https://lore.kernel.org/r/20200719065435.130722-1-leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-07-21tty: xilinx_uartps: Really fix id assignmentHelmut Grohne
The problems started with the revert (18cc7ac8a28e28). The cdns_uart_console.index is statically assigned -1. When the port is registered, Linux assigns consecutive numbers to it. It turned out that when using ttyPS1 as console, the index is not updated as we are reusing the same cdns_uart_console instance for multiple ports. When registering ttyPS0, it gets updated from -1 to 0, but when registering ttyPS1, it already is 0 and not updated. That led to 2ae11c46d5fdc4. It assigns the index prior to registering the uart_driver once. Unfortunately, that ended up breaking the situation where the probe order does not match the id order. When using the same device tree for both uboot and linux, it is important that the serial0 alias points to the console. So some boards reverse those aliases. This was reported by Jan Kiszka. The proposed fix was reverting the index assignment and going back to the previous iteration. However such a reversed assignement (serial0 -> uart1, serial1 -> uart0) was already partially broken by the revert (18cc7ac8a28e28). While the ttyPS device works, the kmsg connection is already broken and kernel messages go missing. Reverting the id assignment does not fix this. >From the xilinx_uartps driver pov (after reverting the refactoring commits), there can be only one console. This manifests in static variables console_pprt and cdns_uart_console. These variables are not properly linked and can go out of sync. The cdns_uart_console.index is important for uart_add_one_port. We call that function for each port - one of which hopefully is the console. If it isn't, the CON_ENABLED flag is not set and console_port is cleared. The next cdns_uart_probe call then tries to register the next port using that same cdns_uart_console. It is important that console_port and cdns_uart_console (and its index in particular) stay in sync. The index assignment implemented by Shubhrajyoti Datta is correct in principle. It just may have to happen a second time if the first cdns_uart_probe call didn't encounter the console device. And we shouldn't change the index once the console uart is registered. Reported-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Reported-by: Jan Kiszka <jan.kiszka@web.de> Link: https://lore.kernel.org/linux-serial/f4092727-d8f5-5f91-2c9f-76643aace993@siemens.com/ Fixes: 18cc7ac8a28e28 ("Revert "serial: uartps: Register own uart console and driver structures"") Fixes: 2ae11c46d5fdc4 ("tty: xilinx_uartps: Fix missing id assignment to the console") Fixes: 76ed2e10579671 ("Revert "tty: xilinx_uartps: Fix missing id assignment to the console"") Signed-off-by: Helmut Grohne <helmut.grohne@intenta.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200713073227.GA3805@laureti-dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21vt: Reject zero-sized screen buffer size.Tetsuo Handa
syzbot is reporting general protection fault in do_con_write() [1] caused by vc->vc_screenbuf == ZERO_SIZE_PTR caused by vc->vc_screenbuf_size == 0 caused by vc->vc_cols == vc->vc_rows == vc->vc_size_row == 0 caused by fb_set_var() from ioctl(FBIOPUT_VSCREENINFO) on /dev/fb0 , for gotoxy(vc, 0, 0) from reset_terminal() from vc_init() from vc_allocate() from con_install() from tty_init_dev() from tty_open() on such console causes vc->vc_pos == 0x10000000e due to ((unsigned long) ZERO_SIZE_PTR) + -1U * 0 + (-1U << 1). I don't think that a console with 0 column or 0 row makes sense. And it seems that vc_do_resize() does not intend to allow resizing a console to 0 column or 0 row due to new_cols = (cols ? cols : vc->vc_cols); new_rows = (lines ? lines : vc->vc_rows); exception. Theoretically, cols and rows can be any range as long as 0 < cols * rows * 2 <= KMALLOC_MAX_SIZE is satisfied (e.g. cols == 1048576 && rows == 2 is possible) because of vc->vc_size_row = vc->vc_cols << 1; vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row; in visual_init() and kzalloc(vc->vc_screenbuf_size) in vc_allocate(). Since we can detect cols == 0 or rows == 0 via screenbuf_size = 0 in visual_init(), we can reject kzalloc(0). Then, vc_allocate() will return an error, and con_write() will not be called on a console with 0 column or 0 row. We need to make sure that integer overflow in visual_init() won't happen. Since vc_do_resize() restricts cols <= 32767 and rows <= 32767, applying 1 <= cols <= 32767 and 1 <= rows <= 32767 restrictions to vc_allocate() will be practically fine. This patch does not touch con_init(), for returning -EINVAL there does not help when we are not returning -ENOMEM. [1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 Reported-and-tested-by: syzbot <syzbot+017265e8553724e514e8@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4Tony Lindgren
Carlos Hernandez <ceh@ti.com> reported that we now have a suspend and resume regresssion on am3 and am4 compared to the earlier kernels. While suspend and resume works with v5.8-rc3, we now get errors with rtcwake: pm33xx pm33xx: PM: Could not transition all powerdomains to target state ... rtcwake: write error This is because we now fail to idle the system timer clocks that the idle code checks and the error gets propagated to the rtcwake. Turns out there are several issues that need to be fixed: 1. Ignore no-idle and no-reset configured timers for the ti-sysc interconnect target driver as otherwise it will keep the system timer clocks enabled 2. Toggle the system timer functional clock for suspend for am3 and am4 (but not for clocksource on am3) 3. Only reconfigure type1 timers in dmtimer_systimer_disable() 4. Use of_machine_is_compatible() instead of of_device_is_compatible() for checking the SoC type Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Reported-by: Carlos Hernandez <ceh@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Carlos Hernandez <ceh@ti.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200713162601.6829-1-tony@atomide.com
2020-07-21usb: xhci: Fix ASM2142/ASM3142 DMA addressingForest Crossman
The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA addresses, which can cause silent memory corruption or IOMMU errors on platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk to fix this issue. Signed-off-by: Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21usb: xhci-mtk: fix the failure of bandwidth allocationChunfeng Yun
The wMaxPacketSize field of endpoint descriptor may be zero as default value in alternate interface, and they are not actually selected when start stream, so skip them when try to allocate bandwidth. Cc: stable <stable@vger.kernel.org> Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller") Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1594360672-2076-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-20net: neterion: vxge: reduce stack usage in VXGE_COMPLETE_VPATH_TXBixuan Cui
Fix the warning: [-Werror=-Wframe-larger-than=] drivers/net/ethernet/neterion/vxge/vxge-main.c: In function'VXGE_COMPLETE_VPATH_TX.isra.37': drivers/net/ethernet/neterion/vxge/vxge-main.c:119:1: warning: the frame size of 1056 bytes is larger than 1024 bytes Dropping the NR_SKB_COMPLETED to 16 is appropriate that won't have much impact on performance and functionality. Signed-off-by: Bixuan Cui <cuibixuan@huawei.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20scsi: core: Run queue in case of I/O resource contention failureMing Lei
I/O requests may be held in scheduler queue because of resource contention. The starvation scenario was handled properly in the regular completion path but we failed to account for it during I/O submission. This lead to the hang captured below. Make sure we run the queue when resource contention is encountered in the submission path. [ 39.054963] scsi 13:0:0:0: rejecting I/O to dead device [ 39.058700] scsi 13:0:0:0: rejecting I/O to dead device [ 39.087855] sd 13:0:0:1: [sdd] Synchronizing SCSI cache [ 39.088909] scsi 13:0:0:1: rejecting I/O to dead device [ 39.095351] scsi 13:0:0:1: rejecting I/O to dead device [ 39.096962] scsi 13:0:0:1: rejecting I/O to dead device [ 247.021859] INFO: task scsi-stress-rem:813 blocked for more than 122 seconds. [ 247.023258] Not tainted 5.8.0-rc2 #8 [ 247.024069] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 247.025331] scsi-stress-rem D 0 813 802 0x00004000 [ 247.025334] Call Trace: [ 247.025354] __schedule+0x504/0x55f [ 247.027987] schedule+0x72/0xa8 [ 247.027991] blk_mq_freeze_queue_wait+0x63/0x8c [ 247.027994] ? do_wait_intr_irq+0x7a/0x7a [ 247.027996] blk_cleanup_queue+0x4b/0xc9 [ 247.028000] __scsi_remove_device+0xf6/0x14e [ 247.028002] scsi_remove_device+0x21/0x2b [ 247.029037] sdev_store_delete+0x58/0x7c [ 247.029041] kernfs_fop_write+0x10d/0x14f [ 247.031281] vfs_write+0xa2/0xdf [ 247.032670] ksys_write+0x6b/0xb3 [ 247.032673] do_syscall_64+0x56/0x82 [ 247.034053] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 247.034059] RIP: 0033:0x7f69f39e9008 [ 247.036330] Code: Bad RIP value. [ 247.036331] RSP: 002b:00007ffdd8116498 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 247.037613] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f69f39e9008 [ 247.039714] RDX: 0000000000000002 RSI: 000055cde92a0ab0 RDI: 0000000000000001 [ 247.039715] RBP: 000055cde92a0ab0 R08: 000000000000000a R09: 00007f69f3a79e80 [ 247.039716] R10: 000000000000000a R11: 0000000000000246 R12: 00007f69f3abb780 [ 247.039717] R13: 0000000000000002 R14: 00007f69f3ab6740 R15: 0000000000000002 Link: https://lore.kernel.org/r/20200720025435.812030-1-ming.lei@redhat.com Cc: linux-block@vger.kernel.org Cc: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-07-20net: ag71xx: add missed clk_disable_unprepare in error path of probeHuang Guobin
The ag71xx_mdio_probe() forgets to call clk_disable_unprepare() when of_reset_control_get_exclusive() failed. Add the missed call to fix it. Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Huang Guobin <huangguobin4@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20nfc: s3fwrn5: add missing release on skb in s3fwrn5_recv_frameNavid Emamdoost
The implementation of s3fwrn5_recv_frame() is supposed to consume skb on all execution paths. Release skb before returning -ENODEV. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20crypto/chtls: correct net_device reference countVinay Kumar Yadav
ip_dev_find() call holds net_device reference which is not needed, use __ip_dev_find() which does not hold reference. v1->v2: - Correct submission tree. - Add fixes tag. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20crypto/chtls: fix tls alert messages corrupted by tls dataVinay Kumar Yadav
When tls data skb is pending for Tx and tls alert comes , It is wrongly overwrite the record type of tls data to tls alert record type. fix the issue correcting it. v1->v2: - Correct submission tree. - Add fixes tag. Fixes: 6919a8264a32 ("Crypto/chtls: add/delete TLS header in driver") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20ionic: use mutex to protect queue operationsShannon Nelson
The ionic_wait_on_bit_lock() was a open-coded mutex knock-off used only for protecting the queue reset operations, and there was no reason not to use the real thing. We can use the lock more correctly and to better protect the queue stop and start operations from cross threading. We can also remove a useless and expensive bit operation from the Rx path. This fixes a case found where the link_status_check from a link flap could run into an MTU change and cause a crash. Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20ionic: keep rss hash after fw updateShannon Nelson
Make sure the RSS hash key is kept across a fw update by not de-initing it when an update is happening. Fixes: c672412f6172 ("ionic: remove lifs on fw reset") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20ionic: update filter id after replayShannon Nelson
When we replay the rx filters after a fw-upgrade we get new filter_id values from the FW, which we need to save and update in our local filter list. This allows us to delete the filters with the correct filter_id when we're done. Fixes: 7e4d47596b68 ("ionic: replay filters after fw upgrade") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20ionic: fix up filter locks and debug msgsShannon Nelson
Add in a couple of forgotten spinlocks and fix up some of the debug messages around filter management. Fixes: c1e329ebec8d ("ionic: Add management of rx filters") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20ionic: use offset for ethtool regs dataShannon Nelson
Use an offset to write the second half of the regs data into the second half of the buffer instead of overwriting the first half. Fixes: 4d03e00a2140 ("ionic: Add initial ethtool support") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20mlxsw: destroy workqueue when trap_register in mlxsw_emad_initLiu Jian
When mlxsw_core_trap_register fails in mlxsw_emad_init, destroy_workqueue() shouled be called to destroy mlxsw_core->emad_wq. Fixes: d965465b60ba ("mlxsw: core: Fix possible deadlock") Signed-off-by: Liu Jian <liujian56@huawei.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20dpaa_eth: Fix one possible memleak in dpaa_eth_probeLiu Jian
When dma_coerce_mask_and_coherent() fails, the alloced netdev need to be freed. Fixes: 060ad66f9795 ("dpaa_eth: change DMA device") Signed-off-by: Liu Jian <liujian56@huawei.com> Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20Merge tag 'ieee802154-for-davem-2020-07-20' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan Stefan Schmidt says: ==================== pull-request: ieee802154 for net 2020-07-20 An update from ieee802154 for your *net* tree. A potential memory leak fix for adf7242 from Liu Jian, and one more HTTPS link change from Alexander A. Klimov. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20net: bcmgenet: add missed clk_disable_unprepare in bcmgenet_probeZhang Changzhong
The driver forgets to call clk_disable_unprepare() in error path after a success calling for clk_prepare_enable(). Fix to goto err_clk_disable if clk_prepare_enable() is successful. Fixes: c80d36ff63a5 ("net: bcmgenet: Use devm_clk_get_optional() to get the clocks") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20net: bcmgenet: fix error returns in bcmgenet_probe()Zhang Changzhong
The driver forgets to call clk_disable_unprepare() in error path after a success calling for clk_prepare_enable(). Fix to goto err_clk_disable if clk_prepare_enable() is successful. Fixes: 99d55638d4b0 ("net: bcmgenet: enable NETIF_F_HIGHDMA flag") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-20Merge tag 'vfio-v5.8-rc7' of git://github.com/awilliam/linux-vfio into masterLinus Torvalds
Pull VFIO fix from Alex Williamson: "Fix race with eventfd ctx cleared outside of mutex (Zeng Tao)" * tag 'vfio-v5.8-rc7' of git://github.com/awilliam/linux-vfio: vfio/pci: fix racy on error and request eventfd ctx
2020-07-20ath10k: Fix NULL pointer dereference in AHB device probeHauke Mehrtens
This fixes a NULL pointer dereference in the probe path for AHB devices. There attr parameter in the ath10k_ce_alloc_pipe() function is not initialized, but accessed. This function is called by ath10k_pci_setup_resource() which is called by ath10k_ahb_probe(). The struct ath10k_pci is also used for AHB devices and not only for PCI devices. The initialization of the new members of struct ath10k_pci is moved to ath10k_pci_setup_resource() which is used by the PCI and the AHB code. This also fixes a use after free bug in ath10k_pci_remove() when ar_pci is accessed after ath10k_core_destroy() was called, which calls ieee80211_free_hw() and frees this memory. This fixes the following bug seen with backports-5.8-rc2 on OpenWrt on a IPQ4019 device: [ 11.117462] 8<--- cut here --- [ 11.117494] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 11.119510] pgd = f377fd58 [ 11.127657] [00000000] *pgd=8e9a0835, *pte=00000000, *ppte=00000000 [ 11.130206] Internal error: Oops: 17 [#1] SMP ARM [ 11.136339] Modules linked in: ath10k_pci(+) ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom gpio_button_hotplug [ 11.174355] CPU: 2 PID: 257 Comm: kmodloader Not tainted 5.4.51 #0 [ 11.196585] Hardware name: Generic DT based system [ 11.202746] PC is at ath10k_ce_alloc_pipe+0x58/0x180 [ath10k_core] [ 11.207459] LR is at ath10k_pci_alloc_pipes+0x94/0xc8 [ath10k_pci] [ 11.213600] pc : [<bf2c96cc>] lr : [<bf2fbf98>] psr: 80000013 [ 11.219760] sp : cea0dc90 ip : cf4001f0 fp : 00000001 [ 11.225923] r10: 00000000 r9 : 00000018 r8 : ce4963b4 [ 11.231133] r7 : 00000000 r6 : ce491ea0 r5 : 00000000 r4 : ce4963b4 [ 11.236342] r3 : 0004a000 r2 : 0004a000 r1 : bf2d0d70 r0 : 00000006 [ 11.242942] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 11.249452] Control: 10c5387d Table: 8e9c006a DAC: 00000051 [ 11.256656] Process kmodloader (pid: 257, stack limit = 0xaba286ca) [ 11.262386] Stack: (0xcea0dc90 to 0xcea0e000) [ 11.268462] dc80: 00000000 ce49629c ce491ea0 ce4963bc [ 11.272984] dca0: ce495ea0 bf2fbf98 00000002 ce4963a8 ce495ea0 00000000 ce491ea0 cf95d800 [ 11.281142] dcc0: cf95d810 cf95d810 00000001 bf2fc854 00000000 cf95d800 bf300748 ce495ea0 [ 11.289304] dce0: ce491ea0 d1300000 cf95d800 bf2fde8c 00000000 00000001 ce49cea0 00000000 [ 11.297462] dd00: 00000000 00000000 bf3010a0 cf95d810 bf3010a0 c0b61580 00000000 00000000 [ 11.305624] dd20: bf3010a0 0000000b c0b04e48 c06110c8 c0b61588 cf95d810 c0b61580 c060f740 [ 11.313781] dd40: cf95d810 00000000 bf3010a0 00000000 00000000 ce49d2a4 bf301100 c060fc90 [ 11.321943] dd60: 00000000 bf3010a0 cf95d810 c060fcf0 cf95d810 bf3010a0 c060fc98 c060dca4 [ 11.330101] dd80: cf809d58 cf952cb4 bf3010a0 ce967900 c0b1f2c8 c060ec28 bf3007b8 bf301038 [ 11.338263] dda0: bf3010a0 bf3010a0 c0b2d4d4 ffffe000 bf304000 c0610278 c0b04e48 c0b2d4d4 [ 11.346422] ddc0: ffffe000 bf2fe2b4 c0b04e48 bf30403c c0b04e48 c0302764 8040003f 00000001 [ 11.354582] dde0: 38e38e39 ce513580 c0b2cb50 cf801e00 cffbc6ac ce513600 cf801e00 cffbc6ac [ 11.362740] de00: 8040003e ce49d280 00000001 c0428d54 00000001 cf801e00 cffbc6ac ce513580 [ 11.370900] de20: ce49d280 0e391998 bf301100 ce49d340 d12d2000 ce49d280 00000001 c0398c2c [ 11.379061] de40: 00000001 cea0df34 cea0df34 00000001 d12d2000 c039ae48 bf30110c 00007fff [ 11.387221] de60: bf301100 c0398044 cf804028 bf301148 c0397674 bf30126c c08ee5c0 c08ee70c [ 11.395380] de80: bf30110c c0b04e48 c08ee518 00000000 c08ee570 c0b04e48 ce513600 fffff000 [ 11.403540] dea0: 00000001 ce513580 0000000d 0000000d 00000000 00000000 00000000 00000000 [ 11.411698] dec0: 00000000 00000000 6e72656b 00006c65 00000000 00000000 00000000 00000000 [ 11.419858] dee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 11.428018] df00: 00000000 0e391998 00000000 0000c610 d12de610 00000000 0062c620 ffffe000 [ 11.436180] df20: 000129d1 00000051 00000000 c039b228 00000000 d12d7afd d12d8e80 d12d2000 [ 11.444337] df40: 0000c610 d12de0e8 d12ddfa8 d12dab74 00009000 00009570 00003a2c 00009cae [ 11.452498] df60: 00000000 00000000 00000000 00003a1c 0000001e 0000001f 00000018 00000000 [ 11.460656] df80: 00000010 00000000 00000000 00000000 00000003 00000080 c0301204 cea0c000 [ 11.468817] dfa0: 00000080 c0301000 00000000 00000000 00620010 0000c610 000129d1 00000014 [ 11.476975] dfc0: 00000000 00000000 00000003 00000080 0000c610 00000000 b6fc1d20 00000000 [ 11.485137] dfe0: bef0ad14 bef0acf8 00011e14 b6f74c94 60000010 00620010 00000000 00000000 [ 11.493390] [<bf2c96cc>] (ath10k_ce_alloc_pipe [ath10k_core]) from [<bf2fbf98>] (ath10k_pci_alloc_pipes+0x94/0xc8 [ath10k_pci]) [ 11.501498] [<bf2fbf98>] (ath10k_pci_alloc_pipes [ath10k_pci]) from [<bf2fc854>] (ath10k_pci_setup_resource+0xb8/0xf0 [ath10k_pci]) [ 11.512773] [<bf2fc854>] (ath10k_pci_setup_resource [ath10k_pci]) from [<bf2fde8c>] (ath10k_ahb_probe+0x32c/0x670 [ath10k_pci]) [ 11.524566] [<bf2fde8c>] (ath10k_ahb_probe [ath10k_pci]) from [<c06110c8>] (platform_drv_probe+0x34/0x70) [ 11.536016] [<c06110c8>] (platform_drv_probe) from [<c060f740>] (really_probe+0x1f0/0x358) [ 11.545729] [<c060f740>] (really_probe) from [<c060fc90>] (device_driver_attach+0x58/0x60) [ 11.553886] [<c060fc90>] (device_driver_attach) from [<c060fcf0>] (__driver_attach+0x58/0xcc) [ 11.562134] [<c060fcf0>] (__driver_attach) from [<c060dca4>] (bus_for_each_dev+0x68/0x8c) [ 11.570731] [<c060dca4>] (bus_for_each_dev) from [<c060ec28>] (bus_add_driver+0x1c8/0x1d8) [ 11.578886] [<c060ec28>] (bus_add_driver) from [<c0610278>] (driver_register+0x74/0x108) [ 11.587060] [<c0610278>] (driver_register) from [<bf2fe2b4>] (ath10k_ahb_init+0x18/0x38 [ath10k_pci]) [ 11.595320] [<bf2fe2b4>] (ath10k_ahb_init [ath10k_pci]) from [<bf30403c>] (init_module+0x3c/0x1000 [ath10k_pci]) [ 11.604432] [<bf30403c>] (init_module [ath10k_pci]) from [<c0302764>] (do_one_initcall+0x84/0x1d8) [ 11.614657] [<c0302764>] (do_one_initcall) from [<c0398c2c>] (do_init_module+0x5c/0x228) [ 11.623421] [<c0398c2c>] (do_init_module) from [<c039ae48>] (load_module+0x1fc8/0x224c) [ 11.631663] [<c039ae48>] (load_module) from [<c039b228>] (sys_init_module+0x15c/0x17c) [ 11.639390] [<c039b228>] (sys_init_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54) [ 11.647370] Exception stack(0xcea0dfa8 to 0xcea0dff0) [ 11.655615] dfa0: 00000000 00000000 00620010 0000c610 000129d1 00000014 [ 11.660569] dfc0: 00000000 00000000 00000003 00000080 0000c610 00000000 b6fc1d20 00000000 [ 11.668725] dfe0: bef0ad14 bef0acf8 00011e14 b6f74c94 [ 11.676886] Code: e1c321d4 e0433002 e0232397 e5843014 (e5953000) [ 11.681958] ---[ end trace 8f35917de2e76854 ]--- Fixes: 521fc37be3d8 ("ath10k: Avoid override CE5 configuration for QCA99X0 chipsets") Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [ipq40xx/ map-ac2200] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200714205802.17688-1-hauke@hauke-m.de
2020-07-20iwlwifi: Make some Killer Wireless-AC 1550 cards work againAlessio Bonfiglio
Fix the regression introduced by commit c8685937d07f ("iwlwifi: move pu devices to new table") by adding the ids and the configurations of two missing Killer 1550 cards in order to configure and let them work correctly again (following the new table convention). Resolve bug 208141 ("Wireless ac 9560 not working kernel 5.7.2", https://bugzilla.kernel.org/show_bug.cgi?id=208141). Fixes: c8685937d07f ("iwlwifi: move pu devices to new table") Signed-off-by: Alessio Bonfiglio <alessio.bonfiglio@mail.polimi.it> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200714091911.4442-1-alessio.bonfiglio@mail.polimi.it
2020-07-20ath9k: Fix regression with Atheros 9271Mark O'Donovan
This fix allows ath9k_htc modules to connect to WLAN once again. Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb") Link: https://bugzilla.kernel.org/show_bug.cgi?id=208251 Signed-off-by: Mark O'Donovan <shiftee@posteo.net> Reported-by: Roman Mamedov <rm@romanrm.net> Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200711043324.8079-1-shiftee@posteo.net
2020-07-20spi: lantiq-ssc: Fix warning by using WQ_MEM_RECLAIMHauke Mehrtens
The lantiq-ssc driver uses internally an own workqueue to wait till the data is not only written out of the FIFO but really written to the wire. This workqueue is flushed while the SPI subsystem is working in some other system workqueue. The system workqueue is marked as WQ_MEM_RECLAIM, but the workqueue in the lantiq-ssc driver does not use WQ_MEM_RECLAIM for now. Add this flag too to prevent this warning. This fixes the following warning: [ 2.975956] WARNING: CPU: 1 PID: 17 at kernel/workqueue.c:2614 check_flush_dependency+0x168/0x184 [ 2.984752] workqueue: WQ_MEM_RECLAIM kblockd:blk_mq_run_work_fn is flushing !WQ_MEM_RECLAIM 1e100800.spi:0x0 Fixes: 891b7c5fbf61 ("mtd_blkdevs: convert to blk-mq") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://lore.kernel.org/r/20200717215648.20522-1-hauke@hauke-m.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-20staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shiftIan Abbott
The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions") Cc: <stable@vger.kernel.org> #3.17+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-20staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shiftIan Abbott
The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this, adjusting the checks for invalid channels so that enabled channel bits that would have been lost by shifting are also checked for validity. Only channels 0 to 15 are valid. Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions") Cc: <stable@vger.kernel.org> #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it Cc: <stable@vger.kernel.org> #4.0+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-20staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shiftIan Abbott
The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG") Cc: <stable@vger.kernel.org> #3.8+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-20staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG supportIan Abbott
`ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions for the "interrupt" subdevice. When `data[0]` is `INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When `data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising and falling edge detection for the digital trigger, using a base channel number (or shift amount) in `data[3]`, a rising edge bitmask in `data[4]` and falling edge bitmask in `data[5]`. If the base channel number (shift amount) is greater than or equal to the number of channels (24) of the digital input subdevice, there are no changes to the rising and falling edges, so the mask of channels to be changed can be set to 0, otherwise the mask of channels to be changed, and the rising and falling edge bitmasks are shifted by the base channel number before calling `ni6527_set_edge_detection()` to change the appropriate registers. Unfortunately, the code is comparing the base channel (shift amount) to the interrupt subdevice's number of channels (1) instead of the digital input subdevice's number of channels (24). Fix it by comparing to 32 because all shift amounts for an `unsigned int` must be less than that and everything from bit 24 upwards is ignored by `ni6527_set_edge_detection()` anyway. Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG") Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-20Merge tag 'misc-habanalabs-fixes-2020-07-19' of ↵Greg Kroah-Hartman
git://people.freedesktop.org/~gabbayo/linux into char-misc-linus Oded writes: This tag contains a single bug fix for 5.8-rc7: - Check that an index is in valid range before using it to access an array. The index is received from the user. This is to prevent a possible out-of-bounds access error. * tag 'misc-habanalabs-fixes-2020-07-19' of git://people.freedesktop.org/~gabbayo/linux: habanalabs: prevent possible out-of-bounds array access
2020-07-20Merge tag 'fpga-late-fixes-for-5.8' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga into char-misc-linus Moritz writes: FPGA manager fixes for 5.8 Here are two (late) dfl fixes for the the 5.8 release. Matthew's fix addresses an issue in the reset of a port. Xu'x fix addresses a linter warning. All patches have been reviewed on the mailing list, and have been in the last few linux-next releases (as part of my fixes branch) without issues. Signed-off-by: Moritz Fischer <mdf@kernel.org> * tag 'fpga-late-fixes-for-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga: fpga: dfl: fix bug in port reset handshake fpga: dfl: pci: reduce the scope of variable 'ret'
2020-07-20net: ieee802154: adf7242: Replace HTTP links with HTTPS onesAlexander A. Klimov
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Link: https://lore.kernel.org/r/20200719113142.58304-1-grandmaster@al2klimov.de Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
2020-07-19bonding: check error value of register_netdevice() immediatelyTaehee Yoo
If register_netdevice() is failed, net_device should not be used because variables are uninitialized or freed. So, the routine should be stopped immediately. But, bond_create() doesn't check return value of register_netdevice() immediately. That will result in a panic because of using uninitialized or freed memory. Test commands: modprobe netdev-notifier-error-inject echo -22 > /sys/kernel/debug/notifier-error-inject/netdev/\ actions/NETDEV_REGISTER/error modprobe bonding max_bonds=3 Splat looks like: [ 375.028492][ T193] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC PTI [ 375.033207][ T193] CPU: 2 PID: 193 Comm: kworker/2:2 Not tainted 5.8.0-rc4+ #645 [ 375.036068][ T193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 375.039673][ T193] Workqueue: events linkwatch_event [ 375.041557][ T193] RIP: 0010:dev_activate+0x4a/0x340 [ 375.043381][ T193] Code: 40 a8 04 0f 85 db 00 00 00 8b 83 08 04 00 00 85 c0 0f 84 0d 01 00 00 31 d2 89 d0 48 8d 04 40 48 c1 e0 07 48 03 83 00 04 00 00 <48> 8b 48 10 f6 41 10 01 75 08 f0 80 a1 a0 01 00 00 fd 48 89 48 08 [ 375.050267][ T193] RSP: 0018:ffff9f8facfcfdd8 EFLAGS: 00010202 [ 375.052410][ T193] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9f8fae6ea000 RCX: 0000000000000006 [ 375.055178][ T193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f8fae6ea000 [ 375.057762][ T193] RBP: ffff9f8fae6ea000 R08: 0000000000000000 R09: 0000000000000000 [ 375.059810][ T193] R10: 0000000000000001 R11: 0000000000000000 R12: ffff9f8facfcfe08 [ 375.061892][ T193] R13: ffffffff883587e0 R14: 0000000000000000 R15: ffff9f8fae6ea580 [ 375.063931][ T193] FS: 0000000000000000(0000) GS:ffff9f8fbae00000(0000) knlGS:0000000000000000 [ 375.066239][ T193] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 375.067841][ T193] CR2: 00007f2f542167a0 CR3: 000000012cee6002 CR4: 00000000003606e0 [ 375.069657][ T193] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 375.071471][ T193] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 375.073269][ T193] Call Trace: [ 375.074005][ T193] linkwatch_do_dev+0x4d/0x50 [ 375.075052][ T193] __linkwatch_run_queue+0x10b/0x200 [ 375.076244][ T193] linkwatch_event+0x21/0x30 [ 375.077274][ T193] process_one_work+0x252/0x600 [ 375.078379][ T193] ? process_one_work+0x600/0x600 [ 375.079518][ T193] worker_thread+0x3c/0x380 [ 375.080534][ T193] ? process_one_work+0x600/0x600 [ 375.081668][ T193] kthread+0x139/0x150 [ 375.082567][ T193] ? kthread_park+0x90/0x90 [ 375.083567][ T193] ret_from_fork+0x22/0x30 Fixes: e826eafa65c6 ("bonding: Call netif_carrier_off after register_netdevice") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-17 04:38:15 +0000