summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-10net: ethernet: lantiq_etop: Fix compilation errorAleksander Jan Bajkowski
This fixes the error detected when compiling the driver. Fixes: 14d4e308e0aa ("net: lantiq: configure the burst length in ethernet drivers") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10selftests: forwarding: Fix packet matching in mirroring selftestsPetr Machata
In commit 6de6e46d27ef ("cls_flower: Fix inability to match GRE/IPIP packets"), cls_flower was fixed to match an outer packet of a tunneled packet as would be expected, rather than dissecting to the inner packet and matching on that. This fix uncovered several issues in packet matching in mirroring selftests: - in mirror_gre_bridge_1d_vlan.sh and mirror_gre_vlan_bridge_1q.sh, the vlan_ethtype match is copied around as "ip", even as some of the tests are running over ip6gretap. This is fixed by using an "ipv6" for vlan_ethtype in the ip6gretap tests. - in mirror_gre_changes.sh, a filter to count GRE packets is set up to match TTL of 50. This used to trigger in the offloaded datapath, where the envelope TTL was matched, but not in the software datapath, which considered TTL of the inner packet. Now that both match consistently, all the packets were double-counted. This is fixed by marking the filter as skip_hw, leaving only the SW datapath component active. Fixes: 6de6e46d27ef ("cls_flower: Fix inability to match GRE/IPIP packets") Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10vsock: prevent unnecessary refcnt inc for nonblocking connectEiichi Tsukata
Currently vosck_connect() increments sock refcount for nonblocking socket each time it's called, which can lead to memory leak if it's called multiple times because connect timeout function decrements sock refcount only once. Fixes it by making vsock_connect() return -EALREADY immediately when sock state is already SS_CONNECTING. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Eiichi Tsukata <eiichi.tsukata@nutanix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: marvell: mvpp2: Fix wrong SerDes reconfiguration orderMarek Behún
Commit bfe301ebbc94 ("net: mvpp2: convert to use mac_prepare()/mac_finish()") introduced a bug wherein it leaves the MAC RESET register asserted after mac_finish(), due to wrong order of function calls. Before it was: .mac_config() mvpp22_mode_reconfigure() assert reset mvpp2_xlg_config() deassert reset Now it is: .mac_prepare() .mac_config() mvpp2_xlg_config() deassert reset .mac_finish() mvpp2_xlg_config() assert reset Obviously this is wrong. This bug is triggered when phylink tries to change the PHY interface mode from a GMAC mode (sgmii, 1000base-x, 2500base-x) to XLG mode (10gbase-r, xaui). The XLG mode does not work since reset is left asserted. Only after ifconfig down && ifconfig up is called will the XLG mode work. Move the call to mvpp22_mode_reconfigure() to .mac_prepare() implementation. Since some of the subsequent functions need to know whether the interface is being changed, we unfortunately also need to pass around the new interface mode before setting port->phy_interface. Fixes: bfe301ebbc94 ("net: mvpp2: convert to use mac_prepare()/mac_finish()") Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: ethernet: ti: cpsw_ale: Fix access to un-initialized memoryChristophe JAILLET
It is spurious to allocate a bitmap without initializing it. So, better safe than sorry, initialize it to 0 at least to have some known values. While at it, switch to the devm_bitmap_ API which is less verbose. Fixes: 4b41d3436796 ("net: ethernet: ti: cpsw: allow untagged traffic on host port") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10virtio-mem: support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLEDavid Hildenbrand
The initial virtio-mem spec states that while unplugged memory should not be read, the device still has to allow for reading unplugged memory inside the usable region. The primary motivation for this default handling was to simplify bringup of virtio-mem, because there were corner cases where Linux might have accidentially read unplugged memory inside added Linux memory blocks. In the meantime, we: 1. Removed /dev/kmem in commit bbcd53c96071 ("drivers/char: remove /dev/kmem for good") 2. Disallowed access to virtio-mem device memory via /dev/mem in commit 2128f4e21aa2 ("virtio-mem: disallow mapping virtio-mem memory via /dev/mem") 3. Sanitized access to virtio-mem device memory via /proc/kcore in commit 0daa322b8ff9 ("fs/proc/kcore: don't read offline sections, logically offline pages and hwpoisoned pages") 4. Sanitized access to virtio-mem device memory via /proc/vmcore in commit ce2814622e84 ("virtio-mem: kdump mode to sanitize /proc/vmcore access") "Accidential" access to unplugged memory is no longer possible; we can support the new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be required by some hypervisors implementing virtio-mem in the near future. Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Cc: Hui Zhu <teawater@gmail.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2021-11-10net: stmmac: allow a tc-taprio base-time of zeroVladimir Oltean
Commit fe28c53ed71d ("net: stmmac: fix taprio configuration when base_time is in the past") allowed some base time values in the past, but apparently not all, the base-time value of 0 (Jan 1st 1970) is still explicitly denied by the driver. Remove the bogus check. Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10selftests: net: test_vxlan_under_vrf: fix HV connectivity testAndrea Righi
It looks like test_vxlan_under_vrf.sh is always failing to verify the connectivity test during the ping between the two simulated VMs. This is due to the fact that veth-hv in each VM should have a distinct MAC address. Fix by setting a unique MAC address on each simulated VM interface. Without this fix: $ sudo ./tools/testing/selftests/net/test_vxlan_under_vrf.sh Checking HV connectivity [ OK ] Check VM connectivity through VXLAN (underlay in the default VRF) [FAIL] With this fix applied: $ sudo ./tools/testing/selftests/net/test_vxlan_under_vrf.sh Checking HV connectivity [ OK ] Check VM connectivity through VXLAN (underlay in the default VRF) [ OK ] Check VM connectivity through VXLAN (underlay in a VRF) [FAIL] NOTE: the connectivity test with the underlay VRF is still failing; it seems that ARP requests are blocked at the simulated hypervisor level, probably due to some missing ARP forwarding rules. This requires more investigation (in the meantime we may consider to set that test as expected failure - XFAIL). Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10Merge branch 'hns3-fixes'David S. Miller
Guangbin Huang says: ==================== net: hns3: add some fixes for -net This series adds some fixes for the HNS3 ethernet driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: allow configure ETS bandwidth of all TCsGuangbin Huang
Currently, driver only allow configuring ETS bandwidth of TCs according to the max TC number queried from firmware. However, the hardware actually supports 8 TCs and users may need to configure ETS bandwidth of all TCs, so remove the restriction. Fixes: 330baff5423b ("net: hns3: add ETS TC weight setting in SSU module") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: remove check VF uc mac exist when set by PFGuangbin Huang
If users set unicast mac address for VFs by PF, they need to guarantee all VFs' address is different. This patch removes the check mac address exist of VFs, for usrs can refresh mac addresses of all VFs directly without need to modify the exist mac address to other value firstly. Fixes: 8e6de441b8e6 ("net: hns3: add support for configuring VF MAC from the host") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: fix some mac statistics is always 0 in device version V2Guangbin Huang
When driver queries the register number of mac statistics from firmware, the old firmware runs in device version V2 only returns number of valid registers, not include number of three reserved registers among of them. It cause driver doesn't record the last three data when query mac statistics. To fix this problem, driver never query register number in device version V2 and set it to a fixed value which include three reserved registers. Fixes: c8af2887c941 ("net: hns3: add support pause/pfc durations for mac statistics") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: fix kernel crash when unload VF while it is being resetYufeng Mo
When fully configure VLANs for a VF, then unload the VF while triggering a reset to PF, will cause a kernel crash because the irq is already uninit. [ 293.177579] ------------[ cut here ]------------ [ 293.183502] kernel BUG at drivers/pci/msi.c:352! [ 293.189547] Internal error: Oops - BUG: 0 [#1] SMP ...... [ 293.390124] Workqueue: hclgevf hclgevf_service_task [hclgevf] [ 293.402627] pstate: 80c00009 (Nzcv daif +PAN +UAO) [ 293.414324] pc : free_msi_irqs+0x19c/0x1b8 [ 293.425429] lr : free_msi_irqs+0x18c/0x1b8 [ 293.436545] sp : ffff00002716fbb0 [ 293.446950] x29: ffff00002716fbb0 x28: 0000000000000000 [ 293.459519] x27: 0000000000000000 x26: ffff45b91ea16b00 [ 293.472183] x25: 0000000000000000 x24: ffffa587b08f4700 [ 293.484717] x23: ffffc591ac30e000 x22: ffffa587b08f8428 [ 293.497190] x21: ffffc591ac30e300 x20: 0000000000000000 [ 293.509594] x19: ffffa58a062a8300 x18: 0000000000000000 [ 293.521949] x17: 0000000000000000 x16: ffff45b91dcc3f48 [ 293.534013] x15: 0000000000000000 x14: 0000000000000000 [ 293.545883] x13: 0000000000000040 x12: 0000000000000228 [ 293.557508] x11: 0000000000000020 x10: 0000000000000040 [ 293.568889] x9 : ffff45b91ea1e190 x8 : ffffc591802d0000 [ 293.580123] x7 : ffffc591802d0148 x6 : 0000000000000120 [ 293.591190] x5 : ffffc591802d0000 x4 : 0000000000000000 [ 293.602015] x3 : 0000000000000000 x2 : 0000000000000000 [ 293.612624] x1 : 00000000000004a4 x0 : ffffa58a1e0c6b80 [ 293.623028] Call trace: [ 293.630340] free_msi_irqs+0x19c/0x1b8 [ 293.638849] pci_disable_msix+0x118/0x140 [ 293.647452] pci_free_irq_vectors+0x20/0x38 [ 293.656081] hclgevf_uninit_msi+0x44/0x58 [hclgevf] [ 293.665309] hclgevf_reset_rebuild+0x1ac/0x2e0 [hclgevf] [ 293.674866] hclgevf_reset+0x358/0x400 [hclgevf] [ 293.683545] hclgevf_reset_service_task+0xd0/0x1b0 [hclgevf] [ 293.693325] hclgevf_service_task+0x4c/0x2e8 [hclgevf] [ 293.702307] process_one_work+0x1b0/0x448 [ 293.710034] worker_thread+0x54/0x468 [ 293.717331] kthread+0x134/0x138 [ 293.724114] ret_from_fork+0x10/0x18 [ 293.731324] Code: f940b000 b4ffff00 a903e7b8 f90017b6 (d4210000) This patch fixes the problem by waiting for the VF reset done while unloading the VF. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: sync rx ring head in echo common pullYufeng Mo
When the driver processes rx packets, the head pointer is updated only after the number of received packets reaches 16. However, hardware relies on the head pointer to calculate the number of FBDs. As a result, the hardware calculates the FBD incorrectly. Therefore, the driver proactively updates the head pointer in each common poll to ensure that the number of FBDs calculated by the hardware is correct. Fixes: 68752b24f51a ("net: hns3: schedule the polling again when allocation fails") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: fix pfc packet number incorrect after querying pfc parametersJie Wang
Currently, driver will send command to firmware to query pfc packet number when user uses dcb tool to get pfc parameters. However, the periodic service task will also periodically query and record MAC statistics, including pfc packet number. As the hardware registers of statistics is cleared after reading, it will cause pfc packet number of MAC statistics are not correct after using dcb tool to get pfc parameters. To fix this problem, when user uses dcb tool to get pfc parameters, driver updates MAC statistics firstly and then get pfc packet number from MAC statistics. Fixes: 64fd2300fcc1 ("net: hns3: add support for querying pfc puase packets statistic") Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: fix ROCE base interrupt vector initialization bugJie Wang
Currently, NIC init ROCE interrupt vector with MSIX interrupt. But ROCE use pci_irq_vector() to get interrupt vector, which adds the relative interrupt vector again and gets wrong interrupt vector. So fixes it by assign relative interrupt vector to ROCE instead of MSIX interrupt vector and delete the unused struct member base_msi_vector declaration of hclgevf_dev. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10net: hns3: fix failed to add reuse multicast mac addr to hardware when mc ↵Guangbin Huang
mac table is full Currently, when driver is failed to add a new multicast mac address to hardware due to the multicast mac table is full, it will directly return. In this case, if the multicast mac list has some reuse addresses after the new address, those reuse addresses will never be added to hardware. To fix this problem, if function hclge_add_mc_addr_common() returns -ENOSPC, hclge_sync_vport_mac_list() should judge whether continue or stop to add next address. As function hclge_sync_vport_mac_list() needs parameter mac_type to know whether is uc or mc, refine this function to add parameter mac_type and remove parameter sync. So does function hclge_unsync_vport_mac_list(). Fixes: ee4bcd3b7ae4 ("net: hns3: refactor the MAC address configure") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-10Merge branch 'thermal-int340x'Rafael J. Wysocki
Merge int340x thermal driver fix for 5.16-rc1. * thermal-int340x: thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses
2021-11-10Merge branches 'pm-opp' and 'pm-cpufreq'Rafael J. Wysocki
Merge operating performance points (OPP) framework updates for and intel_pstate driver fixes for 5.16-rc1. * pm-opp: dt-bindings: opp: Allow multi-worded OPP entry name opp: Fix return in _opp_add_static_v2() PM / devfreq: tegra30: Check whether clk_round_rate() returns zero rate PM / devfreq: tegra30: Use resource-managed helpers PM / devfreq: Add devm_devfreq_add_governor() opp: Add more resource-managed variants of dev_pm_opp_of_add_table() opp: Change type of dev_pm_opp_attach_genpd(names) argument opp: Fix required-opps phandle array count check * pm-cpufreq: cpufreq: intel_pstate: Clear HWP Status during HWP Interrupt enable cpufreq: intel_pstate: Fix unchecked MSR 0x773 access cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
2021-11-10Merge branches 'acpica', 'acpi-ec', 'acpi-pmic' and 'acpi-video'Rafael J. Wysocki
Merge assorted fixes and cleanups and one new backlight quirk list item for 5.16-rc1. * acpica: ACPI: Drop ACPI_USE_BUILTIN_STDARG ifdef from acgcc.h * acpi-ec: ACPI: EC: Remove initialization of static variables to false ACPI: EC: Use ec_no_wakeup on HP ZHAN 66 Pro * acpi-pmic: ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses * acpi-video: ACPI: video: use platform backlight driver on Xiaomi Mi Pad 2 ACPI: video: Drop dmi_system_id.ident settings from video_detect_dmi_table[]
2021-11-10Merge branch 'acpi-dsc'Rafael J. Wysocki
Merge new ACPI device configuration object _DSC support for 5.16-rc1. * acpi-dsc: Documentation: ACPI: Fix non-D0 probe _DSC object example at24: Support probing while in non-zero ACPI D state media: i2c: imx319: Support device probe in non-zero ACPI D state ACPI: Add a convenience function to tell a device is in D0 state Documentation: ACPI: Document _DSC object usage for enum power state i2c: Allow an ACPI driver to manage the device's power state during probe ACPI: scan: Obtain device's desired enumeration power state
2021-11-10Documentation: ACPI: Fix non-D0 probe _DSC object exampleSakari Ailus
The original patch adding the example used _DSC Name when Method was intended. Fix this. Also replace spaces used for indentation with tabs in the example. Fixes: ed66f12ba4b1 ("Documentation: ACPI: Document _DSC object usage for enum power state") Reported-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-09Input: iforce - fix control-message timeoutJohan Hovold
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 487358627825 ("Input: iforce - use DMA-safe buffer when getting IDs from USB") Signed-off-by: Johan Hovold <johan@kernel.org> Cc: stable@vger.kernel.org # 5.3 Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-09Input: wacom_i2c - use macros for the bit masksAlistair Francis
To make the code easier to read use macros for the bit masks. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20211009113707.17568-2-alistair@alistair23.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-10ALSA: memalloc: Remove a stale commentTakashi Iwai
The comment about the reused vmalloc helpers is no longer valid after the recent change for the noncontig allocator. Drop the stale comment. Fixes: ad4f93ca4138 ("ALSA: memalloc: Use proper SG helpers for noncontig allocations") Link: https://lore.kernel.org/r/20211110063100.21359-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-09Input: ili210x - reduce sample period to 15msMarek Vasut
Modern devices may redraw display at 60 Hz, make sure we have one input sample per one frame. Reduce sample period to 15ms, so we would get up to 66.6 samples per second, although realistically with all the jitter and extra scheduling wiggle room, we would end up just above 60 samples per second. This should be a good compromise between sampling too often and sampling too seldom. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20211108114145.84118-1-marex@denx.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-09Input: ili210x - improve polled sample spacingMarek Vasut
Currently the ili210x driver implements a threaded interrupt handler which starts upon edge on the interrupt line, and then polls the touch controller for samples. Every time a sample is obtained from the controller, the thread function checks whether further polling is required, and if so, waits fixed amount of time before polling for next sample. The delay between consecutive samples can thus vary greatly, because the I2C transfer required to retrieve the sample from the controller takes different amount of time on different platforms. Furthermore, different models of the touch controllers supported by this driver require different delays during retrieval of samples too. Instead of waiting fixed amount of time before polling for next sample, determine how much time passed since the beginning of sampling cycle and then wait only the remaining amount of time within the sampling cycle. This makes the driver deliver samples with equal spacing between them. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20211108005216.480525-1-marex@denx.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-09Input: ili210x - special case ili251x sample read outMarek Vasut
The ili251x touch controller needs 5ms delay between sending I2C device address and register address, and, writing or reading register data. According to downstream ili251x example code, this 5ms delay is not required when reading touch samples out of the controller. Implement such a special case. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20211108005259.480545-1-marex@denx.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-09Input: elantench - fix misreporting trackpoint coordinatesPhoenix Huang
Some firmwares occasionally report bogus data from trackpoint, with X or Y displacement being too large (outside of [-127, 127] range). Let's drop such packets so that we do not generate jumps. Signed-off-by: Phoenix Huang <phoenix@emc.com.tw> Tested-by: Yufei Du <yufeidu@cs.unc.edu> Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-09cifs: set a minimum of 120s for next dns resolutionPaulo Alcantara
With commit 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution") and after triggering the first reconnect, the next async dns resolution of tcp server's hostname would be scheduled based on dns_resolver's key expiry default, which happens to default to 5s on most systems that use key.dns_resolver for upcall. As per key.dns_resolver.conf(5): default_ttl=<number> The number of seconds to set as the expiration on a cached record. This will be overridden if the program manages to re- trieve TTL information along with the addresses (if, for exam- ple, it accesses the DNS directly). The default is 5 seconds. The value must be in the range 1 to INT_MAX. Make the next async dns resolution no shorter than 120s as we do not want to be upcalling too often. Cc: stable@vger.kernel.org Fixes: 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution") Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-09cifs: split out dfs code from cifs_reconnect()Paulo Alcantara
Make two separate functions that handle dfs and non-dfs reconnect logics since cifs_reconnect() became way too complex to handle both. While at it, add some documentation. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-09net: mana: Fix spelling mistake "calledd" -> "called"Colin Ian King
There is a spelling mistake in a dev_info message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Link: https://lore.kernel.org/r/20211108201817.43121-1-colin.i.king@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-09net/sched: sch_taprio: fix undefined behavior in ktime_mono_to_anyEric Dumazet
1) if q->tk_offset == TK_OFFS_MAX, then get_tcp_tstamp() calls ktime_mono_to_any() with out-of-bound value. 2) if q->tk_offset is changed in taprio_parse_clockid(), taprio_get_time() might also call ktime_mono_to_any() with out-of-bound value as sysbot found: UBSAN: array-index-out-of-bounds in kernel/time/timekeeping.c:908:27 index 3 is out of range for type 'ktime_t *[3]' CPU: 1 PID: 25668 Comm: kworker/u4:0 Not tainted 5.15.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:291 ktime_mono_to_any+0x1d4/0x1e0 kernel/time/timekeeping.c:908 get_tcp_tstamp net/sched/sch_taprio.c:322 [inline] get_packet_txtime net/sched/sch_taprio.c:353 [inline] taprio_enqueue_one+0x5b0/0x1460 net/sched/sch_taprio.c:420 taprio_enqueue+0x3b1/0x730 net/sched/sch_taprio.c:485 dev_qdisc_enqueue+0x40/0x300 net/core/dev.c:3785 __dev_xmit_skb net/core/dev.c:3869 [inline] __dev_queue_xmit+0x1f6e/0x3630 net/core/dev.c:4194 batadv_send_skb_packet+0x4a9/0x5f0 net/batman-adv/send.c:108 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x6d7/0x8e0 net/batman-adv/bat_iv_ogm.c:1701 process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298 worker_thread+0x658/0x11f0 kernel/workqueue.c:2445 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Fixes: 7ede7b03484b ("taprio: make clock reference conversions easier") Fixes: 54002066100b ("taprio: Adjust timestamps for TCP packets") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Vedang Patel <vedang.patel@intel.com> Reported-by: syzbot <syzkaller@googlegroups.com> Reviewed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Link: https://lore.kernel.org/r/20211108180815.1822479-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-09amt: use cancel_delayed_work() instead of flush_delayed_work() in amt_fini()Taehee Yoo
When the amt module is being removed, it calls flush_delayed_work() to exit source_gc_wq. But it wouldn't be exited properly because the amt_source_gc_work(), which is the callback function of source_gc_wq internally calls mod_delayed_work() again. So, amt_source_gc_work() would be called after the amt module is removed. Therefore kernel panic would occur. In order to avoid it, cancel_delayed_work() should be used instead of flush_delayed_work(). Test commands: modprobe amt modprobe -rv amt Splat looks like: BUG: unable to handle page fault for address: fffffbfff80f50db #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1237ee067 P4D 1237ee067 PUD 1237b2067 PMD 100c11067 PTE 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0+ #27 5a0ebebc29fe5c40c68bea90197606c3a832b09f RIP: 0010:run_timer_softirq+0x221/0xfc0 Code: 00 00 4c 89 e1 4c 8b 30 48 c1 e9 03 80 3c 29 00 0f 85 ed 0b 00 00 4d 89 34 24 4d 85 f6 74 19 49 8d 7e 08 48 89 f9 48 c1 e9 03 <80> 3c 29 00 0f 85 fa 0b 00 00 4d 89 66 08 83 04 24 01 49 89 d4 48 RSP: 0018:ffff888119009e50 EFLAGS: 00010806 RAX: ffff8881191f8a80 RBX: 00000000007ffe2a RCX: 1ffffffff80f50db RDX: ffff888119009ed0 RSI: 0000000000000008 RDI: ffffffffc07a86d8 RBP: dffffc0000000000 R08: ffff8881191f8280 R09: ffffed102323f061 R10: ffff8881191f8307 R11: ffffed102323f060 R12: ffff888119009ec8 R13: 00000000000000c0 R14: ffffffffc07a86d0 R15: ffff8881191f82e8 FS: 0000000000000000(0000) GS:ffff888119000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80f50db CR3: 00000001062dc002 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? add_timer+0x650/0x650 ? kvm_clock_read+0x14/0x30 ? ktime_get+0xb9/0x180 ? rcu_read_lock_held_common+0xe/0xa0 ? rcu_read_lock_sched_held+0x56/0xc0 ? rcu_read_lock_bh_held+0xa0/0xa0 ? hrtimer_interrupt+0x271/0x790 __do_softirq+0x1d0/0x88f irq_exit_rcu+0xe7/0x120 sysvec_apic_timer_interrupt+0x8a/0xb0 </IRQ> <TASK> [ ... ] Fixes: bc54e49c140b ("amt: add multicast(IGMP) report message handler") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://lore.kernel.org/r/20211108145340.17208-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-10Merge tag 'drm-intel-next-fixes-2021-11-09' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next Couple Reverts, build fix, couple virtualization fixes, blank screen and other display rates fixes, and more. Four patches targeting stable in here. Display Fixes: - DP rates related fixes (Imre, Jani) - A Revert on disaling dual eDP that was causing state readout problems (Jani) - put the cdclk vtables in const data (Jani) - Fix DVO port type for moder platforms (Ville) - Fix blankscreen by turning DP++ TMDS output buffers on encoder->shutdown (Ville) - CCS FBs related fixes (Imre) GT fixes: - Fix recursive lock in GuC submission (Matt Brost) - Revert guc_id from i915_request tracepoint (Joonas) - Build fix around dmabuf (Matt Auld) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YYsBif3HMi8GjLoU@intel.com
2021-11-10Merge tag 'drm-misc-next-fixes-2021-11-05' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next A refcounting fix for outstanding fence callbacks. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211105074318.oy6rwjr5wcw6qpjj@gilmour
2021-11-09net: dsa: mv88e6xxx: Don't support >1G speeds on 6191X on ports other than 10Marek Behún
Model 88E6191X only supports >1G speeds on port 10. Port 0 and 9 are only 1G. Fixes: de776d0d316f ("net: dsa: mv88e6xxx: add support for mv88e6393x family") Signed-off-by: Marek Behún <kabel@kernel.org> Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20211104171747.10509-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-09cifs: convert list_for_each to entry variantPaulo Alcantara
Convert list_for_each{,_safe} to list_for_each_entry{,_safe} in cifs_mark_tcp_ses_conns_for_reconnect() function. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-09cifs: introduce new helper for cifs_reconnect()Paulo Alcantara
Create cifs_mark_tcp_ses_conns_for_reconnect() helper to mark all sessions and tcons for reconnect when reconnecting tcp server. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-09cifs: fix print of hdr_flags in dfscache_proc_show()Paulo Alcantara
Reorder the parameters in seq_printf() to correctly print header flags. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-09block: add __must_check for *add_disk*() callersLuis Chamberlain
Now that we have done a spring cleaning on all drivers and added error checking / handling, let's keep it that way and ensure no new drivers fail to stick with it. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20211110002949.999380-1-mcgrof@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-09block: use enum type for blk_mq_alloc_data->rq_flagsJens Axboe
kernel test robot reports that we now trigger some sparse warnings: block/blk-mq.h:169:32: sparse: sparse: restricted req_flags_t degrades to integer block/blk-mq.h:169:32: sparse: sparse: restricted req_flags_t degrades to integer block/blk-mq.h:169:32: sparse: sparse: restricted req_flags_t degrades to integer which is due to ->rq_flags being an unsigned int, rather than the stronger type req_flags_t enum. Change the type to req_flags_t to silence this warning. Fixes: 56f8da642bd8 ("block: add rq_flags to struct blk_mq_alloc_data") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-10rtc: rx8025: use .set_offset/.read_offsetAlexandre Belloni
The driver has its own sysfs file to adjust the clock. Fortunately, it is already in pbb, however, the sign it expects is the opposite of what the RTC core does (which actually aligns with the RTC). Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-12-alexandre.belloni@bootlin.com
2021-11-10rtc: rx8025: use rtc_add_groupAlexandre Belloni
Remove open coded sysfs registration by using rtc_add_group. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-11-alexandre.belloni@bootlin.com
2021-11-10rtc: rx8025: clear RTC_FEATURE_ALARM when alarm are not supportedAlexandre Belloni
Clear RTC_FEATURE_ALARM to signal alarms are not supported to the core instead of checking client->irq. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-10-alexandre.belloni@bootlin.com
2021-11-10rtc: rx8025: set rangeAlexandre Belloni
Set the RTC range, it is a classic BCD RTC, with 00 being a leap year. Let the core handle range checking. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-9-alexandre.belloni@bootlin.com
2021-11-10rtc: rx8025: let the core handle the alarm resolutionAlexandre Belloni
Tell the RTC core UIE are not supported because the resolution of the alarm is a minute. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-8-alexandre.belloni@bootlin.com
2021-11-10rtc: rx8025: switch to devm_rtc_allocate_deviceAlexandre Belloni
Switch to devm_rtc_allocate_device/devm_rtc_register_device, this allows for further improvement of the driver. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-7-alexandre.belloni@bootlin.com
2021-11-10rtc: ab8500: let the core handle the alarm resolutionAlexandre Belloni
Tell the RTC core UIE are not supported because the resolution of the alarm is a minute. Note that this is in fact also fixing how the resolution is reported as the previous test was simply ensuring the alarm was more than a minute in the future while the register has a minute resolution. This would be ok if the alarm was a countdown but ab8500_rtc_read_alarm suggests otherwise and the AB8500 datasheet states that the RTC documentation is not public. Finally, the comment is wrong and what makes the UIE emulation work is uie_unsupported being set. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211107225458.111068-6-alexandre.belloni@bootlin.com
2021-11-10rtc: ab-eoz9: support UIE when availableAlexandre Belloni
The RTC actually supports UIE when an interrupt is available. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-5-alexandre.belloni@bootlin.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-01 21:52:43 +0000