summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-15tipc: only accept encrypted MSG_CRYPTO msgsXin Long
The MSG_CRYPTO msgs are always encrypted and sent to other nodes for keys' deployment. But when receiving in peers, if those nodes do not validate it and make sure it's encrypted, one could craft a malicious MSG_CRYPTO msg to deploy its key with no need to know other nodes' keys. This patch is to do that by checking TIPC_SKB_CB(skb)->decrypted and discard it if this packet never got decrypted. Note that this is also a supplementary fix to CVE-2021-43267 that can be triggered by an unencrypted malicious MSG_CRYPTO msg. Fixes: 1ef6f7c9390f ("tipc: add automatic session key exchange") Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net/wan/fsl_ucc_hdlc: fix sparse warningsChristophe Leroy
CHECK drivers/net/wan/fsl_ucc_hdlc.c drivers/net/wan/fsl_ucc_hdlc.c:309:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:309:57: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:309:57: got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:311:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:311:46: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:311:46: got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:320:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:320:57: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:320:57: got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:322:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:322:46: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:322:46: got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:372:29: warning: incorrect type in assignment (different base types) drivers/net/wan/fsl_ucc_hdlc.c:372:29: expected unsigned short [usertype] drivers/net/wan/fsl_ucc_hdlc.c:372:29: got restricted __be16 [usertype] drivers/net/wan/fsl_ucc_hdlc.c:379:36: warning: restricted __be16 degrades to integer drivers/net/wan/fsl_ucc_hdlc.c:402:12: warning: incorrect type in assignment (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:402:12: expected struct qe_bd [noderef] __iomem *bd drivers/net/wan/fsl_ucc_hdlc.c:402:12: got struct qe_bd *curtx_bd drivers/net/wan/fsl_ucc_hdlc.c:425:20: warning: incorrect type in assignment (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:425:20: expected struct qe_bd [noderef] __iomem *[assigned] bd drivers/net/wan/fsl_ucc_hdlc.c:425:20: got struct qe_bd *tx_bd_base drivers/net/wan/fsl_ucc_hdlc.c:427:16: error: incompatible types in comparison expression (different address spaces): drivers/net/wan/fsl_ucc_hdlc.c:427:16: struct qe_bd [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:427:16: struct qe_bd * drivers/net/wan/fsl_ucc_hdlc.c:462:33: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:506:41: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:528:33: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:552:38: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:596:67: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:611:41: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:851:38: warning: incorrect type in initializer (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:854:40: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:855:40: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:858:39: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:861:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:866:38: warning: incorrect type in initializer (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:868:21: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:870:40: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:871:40: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:873:39: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:993:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:995:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:1004:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:1006:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:724:29: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:815:21: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:1021:29: warning: dereference of noderef expression Most of the warnings are due to DMA memory being incorrectly handled as IO memory. Fix it by doing direct read/write and doing proper dma_rmb() / dma_wmb(). Other problems are type mismatches or lack of use of IO accessors. Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reported-by: kernel test robot <lkp@intel.com> Link: https://lkml.org/lkml/2021/11/12/647 Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: return correct error codeliuguoqiang
When kmemdup called failed and register_net_sysctl return NULL, should return ENOMEM instead of ENOBUFS Signed-off-by: liuguoqiang <liuguoqiang@uniontech.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: stmmac: socfpga: add runtime suspend/resume callback for stratix10 platformMeng Li
According to upstream commit 5ec55823438e("net: stmmac: add clocks management for gmac driver"), it improve clocks management for stmmac driver. So, it is necessary to implement the runtime callback in dwmac-socfpga driver because it doesn't use the common stmmac_pltfr_pm_ops instance. Otherwise, clocks are not disabled when system enters suspend status. Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver") Cc: stable@vger.kernel.org Signed-off-by: Meng Li <Meng.Li@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: fddi: use swap() to make code cleanerYihao Han
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Signed-off-by: Yihao Han <hanyihao@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15hinic: use ARRAY_SIZE instead of ARRAY_LENGuo Zhengkui
ARRAY_SIZE defined in <linux/kernel.h> is safer than self-defined macros to get size of an array such as ARRAY_LEN used here. Because ARRAY_SIZE uses __must_be_array(arr) to ensure arr is really an array. Reported-by: Alejandro Colomar <colomar.6.4.3@gmail.com> Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: usb: ax88179_178a: add TSO featureJacky Chou
On low-effciency embedded platforms, transmission performance is poor due to on Bulk-out with single packet. Adding TSO feature improves the transmission performance and reduces the number of interrupt caused by Bulk-out complete. Reference to module, net: usb: aqc111. Signed-off-by: Jacky Chou <jackychou@asix.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15Merge branch 'bnxt_en-fixes'David S. Miller
Michael Chan says: ==================== bnxt_en: Bug fixes This series includes 3 fixes. The first one fixes a race condition between devlink reload and SR-IOV configuration. The second one fixes a type mismatch warning in devlink fw live patching. The last one fixes unwanted OVS TC dmesg error logs when tc-hw-offload is disabled on bnxt_en. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15bnxt_en: reject indirect blk offload when hw-tc-offload is offSriharsha Basavapatna
The driver does not check if hw-tc-offload is enabled for the device before offloading a flow in the context of indirect block callback. Fix this by checking NETIF_F_HW_TC in the features flag and rejecting the offload request. This will avoid unnecessary dmesg error logs when hw-tc-offload is disabled, such as these: bnxt_en 0000:19:00.1 eno2np1: dev(ifindex=294) not on same switch bnxt_en 0000:19:00.1 eno2np1: Error: bnxt_tc_add_flow: cookie=0xffff8dace1c88000 error=-22 bnxt_en 0000:19:00.0 eno1np0: dev(ifindex=294) not on same switch bnxt_en 0000:19:00.0 eno1np0: Error: bnxt_tc_add_flow: cookie=0xffff8dace1c88000 error=-22 Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com> Fixes: 627c89d00fb9 ("bnxt_en: flow_offload: offload tunnel decap rules via indirect callbacks") Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15bnxt_en: fix format specifier in live patch error messageEdwin Peer
This fixes type mismatch warning. Reported-by: kernel test robot <lkp@intel.com> Fixes: 3c4153394e2c ("bnxt_en: implement firmware live patching") Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15bnxt_en: extend RTNL to VF check in devlink driver_reinitEdwin Peer
The fixes the race condition between configuring SR-IOV and devlink reload. The SR-IOV configure logic already takes the RTNL lock, setting sriov_cfg under the lock while changes are underway. Extend the lock scope in devlink driver_reinit to cover the VF check and don't run concurrently with SR-IOV configure. Reported-by: Leon Romanovsky <leon@kernel.org> Fixes: 228ea8c187d8 ("bnxt_en: implement devlink dev reload driver_reinit") Cc: Leon Romanovsky <leon@kernel.org> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15Merge branch 'mctp-i2c-driver'David S. Miller
Matt Johnston says: ==================== MCTP I2C driver This patch series adds a netdev driver providing MCTP transport over I2C. It applies against net-next using recent MCTP changes there, though also has I2C core changes for review. I'll leave it to maintainers where it should be applied - please let me know if it needs to be submitted differently. The I2C patches were previously sent as RFC though the only feedback there was an ack to 255 bytes for aspeed. The dt-bindings patch went through review on the list. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15mctp i2c: MCTP I2C binding driverMatt Johnston
Provides MCTP network transport over an I2C bus, as specified in DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes. Each I2C bus to be used for MCTP is flagged in devicetree by a 'mctp-controller' property on the bus node. Each flagged bus gets a mctpi2cX net device created based on the bus number. A 'mctp-i2c-controller' I2C client needs to be added under the adapter. In an I2C mux situation the mctp-i2c-controller node must be attached only to the root I2C bus. The I2C client will handle incoming I2C slave block write data for subordinate busses as well as its own bus. In configurations without devicetree a driver instance can be attached to a bus using the I2C slave new_device mechanism. The MCTP core will hold/release the MCTP I2C device while responses are pending (a 6 second timeout or once a socket is closed, response received etc). While held the MCTP I2C driver will lock the I2C bus so that the correct I2C mux remains selected while responses are received. (Ideally we would just lock the mux to keep the current bus selected for the response rather than a full I2C bus lock, but that isn't exposed in the I2C mux API) This driver requires I2C adapters that allow 255 byte transfers (SMBus 3.0) as the specification requires a minimum MTU of 68 bytes. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15dt-bindings: net: New binding mctp-i2c-controllerMatt Johnston
Used to define a local endpoint to communicate with MCTP peripherals attached to an I2C bus. This I2C endpoint can communicate with remote MCTP devices on the I2C bus. In the example I2C topology below (matching the second yaml example) we have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are indicated by the 'mctp-controller' DT property on an I2C bus node. A mctp-i2c-controller I2C client DT node is placed at the top of the mux topology, since only the root I2C adapter will support I2C slave functionality. .-------. |eeprom | .------------. .------. /'-------' | adapter | | mux --@0,i2c5------' | i2c1 ----.*| --@1,i2c6--.--. |............| \'------' \ \ ......... | mctp-i2c- | \ \ \ .mctpB . | controller | \ \ '.0x30 . | | \ ......... \ '.......' | 0x50 | \ .mctpA . \ ......... '------------' '.0x1d . '.mctpC . '.......' '.0x31 . '.......' (mctpX boxes above are remote MCTP devices not included in the DT at present, they can be hotplugged/probed at runtime. A DT binding for specific fixed MCTP devices could be added later if required) Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: npcm7xx: Allow 255 byte block SMBus transfersMatt Johnston
255 byte support has been tested on a npcm750 board Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Tali Perry <tali.perry1@gmail.com> Reviewed-by: Patrick Venture <venture@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: aspeed: Allow 255 byte block transfersMatt Johnston
255 byte transfers have been tested on an AST2500 board Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: dev: Handle 255 byte blocks for i2c ioctlMatt Johnston
I2C_SMBUS is limited to 32 bytes due to compatibility with the 32 byte i2c_smbus_data.block I2C_RDWR allows larger transfers if sufficient sized buffers are passed. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: core: Allow 255 byte transfers for SMBus 3.xMatt Johnston
SMBus 3.0 increased the maximum block transfer size from 32 bytes to 255 bytes. We increase the size of struct i2c_smbus_data's block[] member. i2c_smbus_xfer() and i2c_smbus_xfer_emulated() now support 255 byte block operations, other block functions remain limited to 32 bytes for compatibility with existing callers. We allow adapters to indicate support for the larger size with I2C_FUNC_SMBUS_V3_BLOCK. Most emulated drivers should be able to use 255 byte blocks by replacing I2C_SMBUS_BLOCK_MAX with I2C_SMBUS_V3_BLOCK_MAX though some will have hardware limitations that need testing. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: ethernet: lantiq_etop: fix build errors/warningsRandy Dunlap
Fix build error and warnings reported by kernel test robot: drivers/net/ethernet/lantiq_etop.c: In function 'ltq_etop_probe': drivers/net/ethernet/lantiq_etop.c:673:15: error: implicit declaration of function 'device_property_read_u32' [-Werror=implicit-function-declaration] 673 | err = device_property_read_u32(&pdev->dev, "lantiq,tx-burst-length", &priv->tx_burst_len); drivers/net/ethernet/lantiq_etop.c: At top level: drivers/net/ethernet/lantiq_etop.c:730:1: warning: no previous prototype for 'init_ltq_etop' [-Wmissing-prototypes] 730 | init_ltq_etop(void) drivers/net/ethernet/lantiq_etop.c: In function 'ltq_etop_hw_init': drivers/net/ethernet/lantiq_etop.c:276:25: warning: ignoring return value of 'request_irq' declared with attribute 'warn_unused_result' [-Wunused-result] 276 | request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv); drivers/net/ethernet/lantiq_etop.c:284:25: warning: ignoring return value of 'request_irq' declared with attribute 'warn_unused_result' [-Wunused-result] 284 | request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv); Fixes: 14d4e308e0aa ("net: lantiq: configure the burst length in ethernet drivers") Fixes: dddb29e42770 ("net: lantiq_etop: remove deprecated IRQF_DISABLED") Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202111090621.yjr9xuVj-lkp@intel.com To: netdev@vger.kernel.org Cc: Aleksander Jan Bajkowski <olek2@wp.pl> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: John Crispin <john@phrozen.org> Cc: linux-mips@vger.kernel.org Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: bridge: Slightly optimize 'find_portno()'Christophe JAILLET
The 'inuse' bitmap is local to this function. So we can use the non-atomic '__set_bit()' to save a few cycles. While at it, also remove some useless {}. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15printk: Remove printk.h inclusion in percpu.hAndy Shevchenko
After the commit 42a0bb3f7138 ("printk/nmi: generic solution for safe printk in NMI") the printk.h is not needed anymore in percpu.h. Moreover `make headerdep` complains (an excerpt) In file included from linux/printk.h, from linux/dynamic_debug.h:188 from linux/printk.h:559 <-- here from linux/percpu.h:9 from linux/idr.h:17 include/net/9p/client.h:13: warning: recursive header inclusion Yeah, it's not a root cause of this, but removing will help to reduce the noise. Fixes: 42a0bb3f7138 ("printk/nmi: generic solution for safe printk in NMI") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dennis Zhou <dennis@kernel.org> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20211112140749.80042-1-andriy.shevchenko@linux.intel.com
2021-11-15atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_waitZekun Shen
This bug report shows up when running our research tools. The reports is SOOB read, but it seems SOOB write is also possible a few lines below. In details, fw.len and sw.len are inputs coming from io. A len over the size of self->rpc triggers SOOB. The patch fixes the bugs by adding sanity checks. The bugs are triggerable with compromised/malfunctioning devices. They are potentially exploitable given they first leak up to 0xffff bytes and able to overwrite the region later. The patch is tested with QEMU emulater. This is NOT tested with a real device. Attached is the log we found by fuzzing. BUG: KASAN: slab-out-of-bounds in hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] Read of size 4 at addr ffff888016260b08 by task modprobe/213 CPU: 0 PID: 213 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] __kasan_report.cold+0x37/0x7c ? aq_hw_read_reg_bit+0x60/0x70 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] kasan_report+0xe/0x20 hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] hw_atl_utils_fw_rpc_call+0x95/0x130 [atlantic] hw_atl_utils_fw_rpc_wait+0x176/0x210 [atlantic] hw_atl_utils_mpi_create+0x229/0x2e0 [atlantic] ? hw_atl_utils_fw_rpc_wait+0x210/0x210 [atlantic] ? hw_atl_utils_initfw+0x9f/0x1c8 [atlantic] hw_atl_utils_initfw+0x12a/0x1c8 [atlantic] aq_nic_ndev_register+0x88/0x650 [atlantic] ? aq_nic_ndev_init+0x235/0x3c0 [atlantic] aq_pci_probe+0x731/0x9b0 [atlantic] ? aq_pci_func_init+0xc0/0xc0 [atlantic] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: bnx2x: fix variable dereferenced before checkPavel Skripkin
Smatch says: bnx2x_init_ops.h:640 bnx2x_ilt_client_mem_op() warn: variable dereferenced before check 'ilt' (see line 638) Move ilt_cli variable initialization _after_ ilt validation, because it's unsafe to deref the pointer before validation check. Fixes: 523224a3b3cd ("bnx2x, cnic, bnx2i: use new FW/HSI") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15regmap: allow to define reg_update_bits for no bus configurationAnsuel Smith
Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a dedicated function in regmap_config for reg_update_bits in no bus configuration. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-15net/smc: Transfer remaining wait queue entries during fallbackWen Gu
The SMC fallback is incomplete currently. There may be some wait queue entries remaining in smc socket->wq, which should be removed to clcsocket->wq during the fallback. For example, in nginx/wrk benchmark, this issue causes an all-zeros test result: server: nginx -g 'daemon off;' client: smc_run wrk -c 1 -t 1 -d 5 http://11.200.15.93/index.html Running 5s test @ http://11.200.15.93/index.html 1 threads and 1 connections Thread Stats Avg Stdev Max ± Stdev Latency 0.00us 0.00us 0.00us -nan% Req/Sec 0.00 0.00 0.00 -nan% 0 requests in 5.00s, 0.00B read Requests/sec: 0.00 Transfer/sec: 0.00B The reason for this all-zeros result is that when wrk used SMC to replace TCP, it added an eppoll_entry into smc socket->wq and expected to be notified if epoll events like EPOLL_IN/ EPOLL_OUT occurred on the smc socket. However, once a fallback occurred, wrk switches to use clcsocket. Now it is clcsocket->wq instead of smc socket->wq which will be woken up. The eppoll_entry remaining in smc socket->wq does not work anymore and wrk stops the test. This patch fixes this issue by removing remaining wait queue entries from smc socket->wq to clcsocket->wq during the fallback. Link: https://www.spinics.net/lists/netdev/msg779769.html Signed-off-by: Wen Gu <guwen@linux.alibaba.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15Merge branch 'net-ipa-fixes'David S. Miller
Alex Elder says: ==================== net: ipa: HOLB register write fixes This small series fixes two recently identified bugs related to the way two registers must be written. The registers define whether and when to drop packets if a head-of-line blocking condition is encountered. The "enable" (dropping packets) register must be written twice for newer versions of hardware. And the timer register must not be written while dropping is enabled. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: ipa: disable HOLB drop when updating timerAlex Elder
The head-of-line blocking timer should only be modified when head-of-line drop is disabled. One of the steps in recovering from a modem crash is to enable dropping of packets with timeout of 0 (immediate). We don't know how the modem configured its endpoints, so before we program the timer, we need to ensure HOL_BLOCK is disabled. Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: ipa: HOLB register sometimes must be written twiceAlex Elder
Starting with IPA v4.5, the HOL_BLOCK_EN register must be written twice when enabling head-of-line blocking avoidance. Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: sched: sch_netem: Refactor code in 4-state loss generatorHarshit Mogalapalli
Fixed comments to match description with variable names and refactored code to match the convention as per [1]. To match the convention mapping is done as follows: State 3 - LOST_IN_BURST_PERIOD State 4 - LOST_IN_GAP_PERIOD [1] S. Salsano, F. Ludovici, A. Ordine, "Definition of a general and intuitive loss model for packet networks and its implementation in the Netem module in the Linux kernel" Fixes: a6e2fe17eba4 ("sch_netem: replace magic numbers with enumerate") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: dsa: vsc73xxx: Make vsc73xx_remove() return voidUwe Kleine-König
vsc73xx_remove() returns zero unconditionally and no caller checks the returned value. So convert the function to return no value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: Clean up some inconsistent indentingJiapeng Chong
Eliminate the follow smatch warning: ./include/linux/skbuff.h:4229 skb_remcsum_process() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15tun: fix bonding active backup with arp monitoringNicolas Dichtel
As stated in the bonding doc, trans_start must be set manually for drivers using NETIF_F_LLTX: Drivers that use NETIF_F_LLTX flag must also update netdev_queue->trans_start. If they do not, then the ARP monitor will immediately fail any slaves using that driver, and those slaves will stay down. Link: https://www.kernel.org/doc/html/v5.15/networking/bonding.html#arp-monitor-operation Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15tipc: use consistent GFP flagsTadeusz Struk
Some functions, like tipc_crypto_start use inconsisten GFP flags when allocating memory. The mentioned function use GFP_ATOMIC to to alloc a crypto instance, and then calls alloc_ordered_workqueue() which allocates memory with GFP_KERNEL. tipc_aead_init() function even uses GFP_KERNEL and GFP_ATOMIC interchangeably. No doc comment specifies what context a function is designed to work in, but the flags should at least be consistent within a function. Cc: Jon Maloy <jmaloy@redhat.com> Cc: Ying Xue <ying.xue@windriver.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: tipc-discussion@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: stmmac: enhance XDP ZC driver level switching performanceOng Boon Leong
The previous stmmac_xdp_set_prog() implementation uses stmmac_release() and stmmac_open() which tear down the PHY device and causes undesirable autonegotiation which causes a delay whenever AFXDP ZC is setup. This patch introduces two new functions that just sufficiently tear down DMA descriptors, buffer, NAPI process, and IRQs and reestablish them accordingly in both stmmac_xdp_release() and stammac_xdp_open(). As the results of this enhancement, we get rid of transient state introduced by the link auto-negotiation: $ ./xdpsock -i eth0 -t -z sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 634444 634560 sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 632330 1267072 sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 632438 1899584 sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 632502 2532160 Reported-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Tested-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15x86/hyperv: Move required MSRs check to initial platform probingSean Christopherson
Explicitly check for MSR_HYPERCALL and MSR_VP_INDEX support when probing for running as a Hyper-V guest instead of waiting until hyperv_init() to detect the bogus configuration. Add messages to give the admin a heads up that they are likely running on a broken virtual machine setup. At best, silently disabling Hyper-V is confusing and difficult to debug, e.g. the kernel _says_ it's using all these fancy Hyper-V features, but always falls back to the native versions. At worst, the half baked setup will crash/hang the kernel. Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20211104182239.1302956-3-seanjc@google.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-11-15x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup failsSean Christopherson
Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30 Fixes: 93286261de1b ("x86/hyperv: Reenlightenment notifications support") Cc: stable@vger.kernel.org Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20211104182239.1302956-2-seanjc@google.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-11-15Drivers: hv: balloon: Use VMBUS_RING_SIZE() wrapper for dm_ring_sizeBoqun Feng
Baihua reported an error when boot an ARM64 guest with PAGE_SIZE=64k and BALLOON is enabled: hv_vmbus: registering driver hv_balloon hv_vmbus: probe failed for device 1eccfd72-4b41-45ef-b73a-4a6e44c12924 (-22) The cause of this is that the ringbuffer size for hv_balloon is not adjusted with VMBUS_RING_SIZE(), which makes the size not large enough for ringbuffers on guest with PAGE_SIZE=64k. Therefore use VMBUS_RING_SIZE() to calculate the ringbuffer size. Note that the old size (20 * 1024) counts a 4k header in the total size, while VMBUS_RING_SIZE() expects the parameter as the payload size, so use 16 * 1024. Cc: <stable@vger.kernel.org> # 5.15.x Reported-by: Baihua Lu <baihua.lu@microsoft.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20211101150026.736124-1-boqun.feng@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-11-15mac80211: fix throughput LED triggerFelix Fietkau
The codepaths for rx with decap offload and tx with itxq were not updating the counters for the throughput led trigger. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20211113063415.55147-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15mac80211: fix monitor_sdata RCU/locking assertionsJohannes Berg
Since commit a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") we've not only been protecting the pointer to monitor_sdata with the RTNL, but also with the wiphy->mtx. This is relevant in a number of lockdep assertions, e.g. the one we hit in ieee80211_set_monitor_channel(). However, we're now protecting all the assignments/dereferences, even the one in interface iter, with the wiphy->mtx, so switch over the lockdep assertions to that lock. Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20211112135143.cb8e8ceffef3.Iaa210f16f6904c8a7a24954fb3396da0ef86ec08@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15mac80211: drop check for DONT_REORDER in __ieee80211_select_queueFelix Fietkau
When __ieee80211_select_queue is called, skb->cb has not been cleared yet, which means that info->control.flags can contain garbage. In some cases this leads to IEEE80211_TX_CTRL_DONT_REORDER being set, causing packets marked for other queues to randomly end up in BE instead. This flag only needs to be checked in ieee80211_select_queue_80211, since the radiotap parser is the only piece of code that sets it Fixes: 66d06c84730c ("mac80211: adhere to Tx control flag that prevents frame reordering") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20211110212201.35452-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15mac80211: fix radiotap header generationJohannes Berg
In commit 8c89f7b3d3f2 ("mac80211: Use flex-array for radiotap header bitmap") we accidentally pointed the position to the wrong place, so we overwrite a present bitmap, and thus cause all kinds of trouble. To see the issue, note that the previous code read: pos = (void *)(it_present + 1); The requirement now is that we need to calculate pos via it_optional, to not trigger the compiler hardening checks, as: pos = (void *)&rthdr->it_optional[...]; Rewriting the original expression, we get (obviously, since that just adds "+ x - x" terms): pos = (void *)(it_present + 1 + rthdr->it_optional - rthdr->it_optional) and moving the "+ rthdr->it_optional" outside to be used as an array: pos = (void *)&rthdr->it_optional[it_present + 1 - rthdr->it_optional]; The original is off by one, fix it. Cc: stable@vger.kernel.org Fixes: 8c89f7b3d3f2 ("mac80211: Use flex-array for radiotap header bitmap") Reported-by: Sid Hayn <sidhayn@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Sid Hayn <sidhayn@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211109100203.c61007433ed6.I1dade57aba7de9c4f48d68249adbae62636fd98c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15docs: filesystems: Fix grammatical error "with" to "which"Wasin Thonkaew
Signed-off-by: Wasin Thonkaew <wasin@wasin.io> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2021-11-15mac80211: do not access the IV when it was strippedXing Song
ieee80211_get_keyid() will return false value if IV has been stripped, such as return 0 for IP/ARP frames due to LLC header, and return -EINVAL for disassociation frames due to its length... etc. Don't try to access it if it's not present. Signed-off-by: Xing Song <xing.song@mediatek.com> Link: https://lore.kernel.org/r/20211101024657.143026-1-xing.song@mediatek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15doc/zh_CN: fix a translation error in management-styleAlex Shi
'The name of the game' means the most important part of an activity, so we should translate it by the meaning instead of the words. Suggested-by: Xinyong Wang <wang.xy.chn@gmail.com> Signed-off-by: Alex Shi <alexs@kernel.org> Reviewed-by: Yanteng Si <siyanteng@loongson.cn> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2021-11-15nl80211: fix radio statistics in survey dumpJohannes Berg
Even if userspace specifies the NL80211_ATTR_SURVEY_RADIO_STATS attribute, we cannot get the statistics because we're not really parsing the incoming attributes properly any more. Fix this by passing the attrbuf to nl80211_prepare_wdev_dump() and filling it there, if given, and using a local version only if no output is desired. Since I'm touching it anyway, make nl80211_prepare_wdev_dump() static. Fixes: 50508d941c18 ("cfg80211: use parallel_ops for genl") Reported-by: Jan Fuchs <jf@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Sven Eckelmann <sven@narfation.org> Link: https://lore.kernel.org/r/20211029092539.2851b4799386.If9736d4575ee79420cbec1bd930181e1d53c7317@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15cfg80211: call cfg80211_stop_ap when switch from P2P_GO typeNguyen Dinh Phi
If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt. Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com> Reported-by: syzbot+bbf402b783eeb6d908db@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20211027173722.777287-1-phind.uet@gmail.com Cc: stable@vger.kernel.org Fixes: ac800140c20e ("cfg80211: .stop_ap when interface is going down") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-11-15docs: ftrace: fix the wrong path of tracefsZhaoyu Liu
Delete "tracing" due to it has been included in /proc/mounts. Delete "echo nop > $tracefs/tracing/current_tracer", maybe this command is redundant. Signed-off-by: Zhaoyu Liu <zackary.liu.pro@gmail.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2021-11-15Documentation: arm: marvell: Fix link to armada_1000_pb.pdf documentPali Rohár
File armada_1000_pb.pdf is not available on Marvell website anymore. So update link to webarchive where is backup copy. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2021-11-15Documentation: arm: marvell: Put Armada XP section between Armada 370 and 375Pali Rohár
From evolution and feature point of view Armada XP belongs between Armada 370 and Armada 375 families. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2021-11-15Documentation: arm: marvell: Add some links to homepage / product infosPali Rohár
Webarchive contains some useful resources like product info or links to other documents. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
generated by cgit (git 2.34.1) at 2025-09-11 13:34:15 +0000