aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-02-19selftests/bpf: Fix a clang deprecated-declarations compilation errorYonghong Song1-0/+3
Build the kernel and selftest with clang compiler with LLVM=1, make -j LLVM=1 make -C tools/testing/selftests/bpf -j LLVM=1 I hit the following selftests/bpf compilation error: In file included from test_cpp.cpp:3: /.../tools/testing/selftests/bpf/tools/include/bpf/libbpf.h:73:8: error: 'relaxed_core_relocs' is deprecated: libbpf v0.6+: field has no effect [-Werror,-Wdeprecated-declarations] struct bpf_object_open_opts { ^ test_cpp.cpp:56:2: note: in implicit move constructor for 'bpf_object_open_opts' first required here LIBBPF_OPTS(bpf_object_open_opts, opts); ^ /.../tools/testing/selftests/bpf/tools/include/bpf/libbpf_common.h:77:3: note: expanded from macro 'LIBBPF_OPTS' (struct TYPE) { \ ^ /.../tools/testing/selftests/bpf/tools/include/bpf/libbpf.h:90:2: note: 'relaxed_core_relocs' has been explicitly marked deprecated here LIBBPF_DEPRECATED_SINCE(0, 6, "field has no effect") ^ /.../tools/testing/selftests/bpf/tools/include/bpf/libbpf_common.h:24:4: note: expanded from macro 'LIBBPF_DEPRECATED_SINCE' (LIBBPF_DEPRECATED("libbpf v" # major "." # minor "+: " msg)) ^ /.../tools/testing/selftests/bpf/tools/include/bpf/libbpf_common.h:19:47: note: expanded from macro 'LIBBPF_DEPRECATED' #define LIBBPF_DEPRECATED(msg) __attribute__((deprecated(msg))) There are two ways to fix the issue, one is to use GCC diagnostic ignore pragma, and the other is to open code bpf_object_open_opts instead of using LIBBPF_OPTS. Since in general LIBBPF_OPTS is preferred, the patch fixed the issue by adding proper GCC diagnostic ignore pragmas. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220217194005.2765348-1-yhs@fb.com
2022-02-20netfilter: nf_tables_offload: incorrect flow offload action array sizePablo Neira Ayuso6-5/+26
immediate verdict expression needs to allocate one slot in the flow offload action array, however, immediate data expression does not need to do so. fwd and dup expression need to allocate one slot, this is missing. Add a new offload_action interface to report if this expression needs to allocate one slot in the flow offload action array. Fixes: be2861dc36d7 ("netfilter: nft_{fwd,dup}_netdev: add offload support") Reported-and-tested-by: Nick Gregory <Nick.Gregory@Sophos.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2022-02-20ata: pata_hpt37x: merge transfer mode setting methodsSergey Shtylyov1-62/+13
After commit e0afcf140e6e ("ata: pata_hpt37x: disable fast interrupts in prereset() method") HPT370's and HPT372+'s PIO/DMA mode setting functions have become identical -- merge them. Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-20ata: libata-sff: use *switch* statement in ata_sff_dev_classify()Sergey Shtylyov1-7/+10
In ata_sff_dev_classify(), replace a string of the *if* statements checking the device's class with the *switch* statement that fits better here... While at it, fix the multi-line comment style in the vicinity... Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-20ata: add/use ata_taskfile::{error|status} fieldsSergey Shtylyov21-84/+90
Add the explicit error and status register fields to 'struct ata_taskfile' using the anonymous *union*s ('struct ide_taskfile' had that for ages!) and update the libata taskfile code accordingly. There should be no object code changes resulting from that... Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-20ata: Kconfig: fix sata gemini compile test conditionDamien Le Moal1-1/+1
When compile testing the sata gemini driver, CONFIG_OF is required to avoid the warning: drivers/ata/sata_gemini.c:421:34: error: ‘gemini_sata_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-20ata: libata-scsi: use *switch* statements to check SCSI command codesSergey Shtylyov1-7/+19
Replace strings of the *if* statements checking the SCSI command code with the *switch* statements that fit better here... Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-20ata: libata-sff: refactor ata_sff_altstatus()Sergey Shtylyov1-26/+33
The driver's calls to ata_sff_altstatus() are mostly surrounded by some clumsy checks. Refactor ata_sff_altstatus() to include the repetitive checks and return a 'bool' result indicating if the alternate status register exists or not. While at it, further update the 'kernel-doc' comment -- the alternate status register has never been a part of the taskfile, despite what Jeff and co. think! :-) In ata_sff_lost_interrupt(), wrap the ata_sff_altstatus() call in a WARN_ON_ONCE() check to issue a warning if the device control register does not exist. And while at it, fix the strange argument indentation in the ata_port_warn() call following the call to ata_sff_altstatus(). Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-19net: dsa: avoid call to __dev_set_promiscuity() while rtnl_mutex isn't heldVladimir Oltean2-7/+20
If the DSA master doesn't support IFF_UNICAST_FLT, then the following call path is possible: dsa_slave_switchdev_event_work -> dsa_port_host_fdb_add -> dev_uc_add -> __dev_set_rx_mode -> __dev_set_promiscuity Since the blamed commit, dsa_slave_switchdev_event_work() no longer holds rtnl_lock(), which triggers the ASSERT_RTNL() from __dev_set_promiscuity(). Taking rtnl_lock() around dev_uc_add() is impossible, because all the code paths that call dsa_flush_workqueue() do so from contexts where the rtnl_mutex is already held - so this would lead to an instant deadlock. dev_uc_add() in itself doesn't require the rtnl_mutex for protection. There is this comment in __dev_set_rx_mode() which assumes so: /* Unicast addresses changes may only happen under the rtnl, * therefore calling __dev_set_promiscuity here is safe. */ but it is from commit 4417da668c00 ("[NET]: dev: secondary unicast address support") dated June 2007, and in the meantime, commit f1f28aa3510d ("netdev: Add addr_list_lock to struct net_device."), dated July 2008, has added &dev->addr_list_lock to protect this instead of the global rtnl_mutex. Nonetheless, __dev_set_promiscuity() does assume rtnl_mutex protection, but it is the uncommon path of what we typically expect dev_uc_add() to do. So since only the uncommon path requires rtnl_lock(), just check ahead of time whether dev_uc_add() would result into a call to __dev_set_promiscuity(), and handle that condition separately. DSA already configures the master interface to be promiscuous if the tagger requires this. We can extend this to also cover the case where the master doesn't handle dev_uc_add() (doesn't support IFF_UNICAST_FLT), and on the premise that we'd end up making it promiscuous during operation anyway, either if a DSA slave has a non-inherited MAC address, or if the bridge notifies local FDB entries for its own MAC address, the address of a station learned on a foreign port, etc. Fixes: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") Reported-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19scsi: libsas: Add sas_abort_task()John Garry5-259/+20
Add a generic implementation of abort task TMF handler, and use in LLDDs. With that, some LLDDs custom TMF functions can now be deleted. Link: https://lore.kernel.org/r/1645112566-115804-18-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_query_task()John Garry5-25/+20
Add a generic implementation of query task TMF handler, and use in LLDDs. Link: https://lore.kernel.org/r/1645112566-115804-17-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_lu_reset()John Garry5-9/+14
Add a generic implementation of LU reset TMF handler, and use in LLDDs. Link: https://lore.kernel.org/r/1645112566-115804-16-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_clear_task_set()John Garry7-20/+14
Add a generic implementation of clear task set TMF handler, and use in LLDDs. Link: https://lore.kernel.org/r/1645112566-115804-15-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_abort_task_set()John Garry9-31/+17
Add a generic implementation of abort task set TMF handler, and use in LLDDs. Link: https://lore.kernel.org/r/1645112566-115804-14-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add TMF handler aborted callbackJohn Garry6-0/+33
The hisi_sas and pm8001 TMF handlers have some special processing for when the TMF is aborted, so add a callback and fill it in for those drivers. Link: https://lore.kernel.org/r/1645112566-115804-13-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add TMF handler exec complete callbackJohn Garry5-0/+22
The pm8001 TMF handler has some special processing when the TMF completes, so add a callback and fill it in for the pm8001 driver. Link: https://lore.kernel.org/r/1645112566-115804-12-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_execute_ssp_tmf()John Garry1-0/+18
Add a function to issue an SSP TMF. Add a temp prototype to keep make W=1 happy. Link: https://lore.kernel.org/r/1645112566-115804-11-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_execute_tmf()John Garry2-0/+108
Drivers using libsas have to issue their own TMFs, and the code to do this is duplicated between drivers. Add a common function to handle TMFs. This will be also used for sending ATA commands, but use name "tmf" as the purpose is similar between SCSI and ATA in the usage. The force_phy_id argument will be used for a hisi_sas HW bug workaround. We check the sas task status stat field against TMF codes, as according to the SAS v1.1 spec 9.2.2.5.3, if response_data is in datapres, then the response code should be a TMF code - see table 128. Link: https://lore.kernel.org/r/1645112566-115804-10-git-send-email-john.garry@huawei.com Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add sas_task.tmfJohn Garry4-37/+23
Add a pointer to a sas_tmf_task to the sas_task struct, as this will be used when the common LLDD TMF code is factored out. Also set it for the LLDDs to store per-sas_task TMF info. Link: https://lore.kernel.org/r/1645112566-115804-9-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Add struct sas_tmf_taskJohn Garry11-56/+49
Some of the LLDDs which use libsas have their own definition of a struct to hold TMF info, so add a common struct for libsas. Also add an interim force phy id field for hisi_sas driver, which will be removed once the STP "TMF" code is factored out. Even though some LLDDs (pm8001) use a u32 for the tag, u16 will be adequate, as that named driver only uses tags in range [0, 1024). Link: https://lore.kernel.org/r/1645112566-115804-8-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Move SMP task handlers to coreJohn Garry3-22/+29
Move the SMP task handlers to the core host code as they will be re-used for executing internal abort and TMF tasks. Link: https://lore.kernel.org/r/1645112566-115804-7-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: hisi_sas: Delete unused I_T_NEXUS_RESET_PHYUP_TIMEOUTJohn Garry1-2/+0
There is no user, so delete it. Link: https://lore.kernel.org/r/1645112566-115804-6-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Delete SAS_SG_ERRJohn Garry3-6/+0
No LLDD sets exec status as SAS_SG_ERR, so remove support. Link: https://lore.kernel.org/r/1645112566-115804-5-git-send-email-john.garry@huawei.com Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Delete lldd_clear_aca callbackJohn Garry15-72/+0
This callback is never called, so remove support. Link: https://lore.kernel.org/r/1645112566-115804-4-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Jack Wang <jinpu.wang@ionos.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Use enum for response frame DATAPRES fieldJohn Garry5-10/+22
As defined in table 126 of the SAS spec 1.1, use an enum for the DATAPRES field, which makes reading the code easier. Also change sas_ssp_task_response() to use a switch statement, which is more suitable (than if-else), as suggested by Christoph. Link: https://lore.kernel.org/r/1645112566-115804-3-git-send-email-john.garry@huawei.com Suggested-by: Xiang Chen <chenxiang66@hisilicon.com> Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19scsi: libsas: Handle non-TMF codes in sas_scsi_find_task()John Garry1-2/+4
LLDD TMF callbacks may return linux or other error codes instead of TMF codes. This may cause problems in sas_scsi_find_task() -> .lldd_query_task(), as only TMF codes are handled there. As such, we may not return a task_disposition type from sas_scsi_find_task(). Function sas_eh_handle_sas_errors() only handles that type, and will only progress error handling for those recognised types. Return TASK_ABORT_FAILED upon exit on the assumption that the command may still be alive and error handling should be escalated. Link: https://lore.kernel.org/r/1645112566-115804-2-git-send-email-john.garry@huawei.com Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-02-19net: prestera: acl: fix 'client_map' buff overflowVolodymyr Mytnyk1-1/+1
smatch warnings: drivers/net/ethernet/marvell/prestera/prestera_acl.c:103 prestera_acl_chain_to_client() error: buffer overflow 'client_map' 3 <= 3 prestera_acl_chain_to_client(u32 chain_index, ...) ... u32 client_map[] = { PRESTERA_HW_COUNTER_CLIENT_LOOKUP_0, PRESTERA_HW_COUNTER_CLIENT_LOOKUP_1, PRESTERA_HW_COUNTER_CLIENT_LOOKUP_2 }; if (chain_index > ARRAY_SIZE(client_map)) ... Fixes: fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: add ksz8563 to ksz9477 I2C driverAhmad Fatoum1-0/+1
The KSZ9477 SPI driver already has support for the KSZ8563. The same switch chip can also be managed via i2c and we have an KSZ9477 I2C driver, but that one lacks the relevant compatible entry. Add it. DT bindings already describe this compatible. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net/smc: unlock on error paths in __smc_setsockopt()Dan Carpenter1-4/+8
These two error paths need to release_sock(sk) before returning. Fixes: a6a6fe27bab4 ("net/smc: Dynamic control handshake limitation by socket options") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: D. Wythe <alibuda@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: ksz9477: export HW stats over stats64 interfaceOleksij Rempel3-0/+104
Provide access to HW offloaded packets over stats64 interface. The rx/tx_bytes values needed some fixing since HW is accounting size of the Ethernet frame together with FCS. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19Merge branch 'phylink-remove-pcs_poll'David S. Miller4-10/+1
Russell King says: ==================== net: phylink: remove pcs_poll This small series removes the now unused pcs_poll members from DSA and phylink. "git grep pcs_poll drivers/net/ net/" on net-next confirms that the only places that reference this are in DSA core code and phylink code: drivers/net/phy/phylink.c: if (pl->config->pcs_poll || pcs->poll) drivers/net/phy/phylink.c: poll |= pl->config->pcs_poll; net/dsa/port.c: dp->pl_config.pcs_poll = ds->pcs_poll; ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: phylink: remove phylink_config's pcs_pollRussell King (Oracle)2-4/+1
phylink_config's pcs_poll is no longer used, let's get rid of it. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: remove pcs_pollRussell King (Oracle)2-6/+0
With drivers converted over to using phylink PCS, there is no need for the struct dsa_switch member "pcs_poll" to exist anymore - there is a flag in the struct phylink_pcs which indicates whether this PCS needs to be polled which supersedes this. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: hsr: fix suspicious RCU usage warning in hsr_node_get_first()Juhee Kang2-7/+11
When hsr_create_self_node() calls hsr_node_get_first(), the suspicious RCU usage warning is occurred. The reason why this warning is raised is the callers of hsr_node_get_first() use rcu_read_lock_bh() and other different synchronization mechanisms. Thus, this patch solved by replacing rcu_dereference() with rcu_dereference_bh_check(). The kernel test robot reports: [ 50.083470][ T3596] ============================= [ 50.088648][ T3596] WARNING: suspicious RCU usage [ 50.093785][ T3596] 5.17.0-rc3-next-20220208-syzkaller #0 Not tainted [ 50.100669][ T3596] ----------------------------- [ 50.105513][ T3596] net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage! [ 50.113799][ T3596] [ 50.113799][ T3596] other info that might help us debug this: [ 50.113799][ T3596] [ 50.124257][ T3596] [ 50.124257][ T3596] rcu_scheduler_active = 2, debug_locks = 1 [ 50.132368][ T3596] 2 locks held by syz-executor.0/3596: [ 50.137863][ T3596] #0: ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x3be/0xb80 [ 50.147470][ T3596] #1: ffff88807ec9d5f0 (&hsr->list_lock){+...}-{2:2}, at: hsr_create_self_node+0x225/0x650 [ 50.157623][ T3596] [ 50.157623][ T3596] stack backtrace: [ 50.163510][ T3596] CPU: 1 PID: 3596 Comm: syz-executor.0 Not tainted 5.17.0-rc3-next-20220208-syzkaller #0 [ 50.173381][ T3596] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 50.183623][ T3596] Call Trace: [ 50.186904][ T3596] <TASK> [ 50.189844][ T3596] dump_stack_lvl+0xcd/0x134 [ 50.194640][ T3596] hsr_node_get_first+0x9b/0xb0 [ 50.199499][ T3596] hsr_create_self_node+0x22d/0x650 [ 50.204688][ T3596] hsr_dev_finalize+0x2c1/0x7d0 [ 50.209669][ T3596] hsr_newlink+0x315/0x730 [ 50.214113][ T3596] ? hsr_dellink+0x130/0x130 [ 50.218789][ T3596] ? rtnl_create_link+0x7e8/0xc00 [ 50.223803][ T3596] ? hsr_dellink+0x130/0x130 [ 50.228397][ T3596] __rtnl_newlink+0x107c/0x1760 [ 50.233249][ T3596] ? rtnl_setlink+0x3c0/0x3c0 [ 50.238043][ T3596] ? is_bpf_text_address+0x77/0x170 [ 50.243362][ T3596] ? lock_downgrade+0x6e0/0x6e0 [ 50.248219][ T3596] ? unwind_next_frame+0xee1/0x1ce0 [ 50.253605][ T3596] ? entry_SYSCALL_64_after_hwframe+0x44/0xae [ 50.259669][ T3596] ? __sanitizer_cov_trace_cmp4+0x1c/0x70 [ 50.265423][ T3596] ? is_bpf_text_address+0x99/0x170 [ 50.270819][ T3596] ? kernel_text_address+0x39/0x80 [ 50.275950][ T3596] ? __kernel_text_address+0x9/0x30 [ 50.281336][ T3596] ? unwind_get_return_address+0x51/0x90 [ 50.286975][ T3596] ? create_prof_cpu_mask+0x20/0x20 [ 50.292178][ T3596] ? arch_stack_walk+0x93/0xe0 [ 50.297172][ T3596] ? kmem_cache_alloc_trace+0x42/0x2c0 [ 50.302637][ T3596] ? rcu_read_lock_sched_held+0x3a/0x70 [ 50.308194][ T3596] rtnl_newlink+0x64/0xa0 [ 50.312524][ T3596] ? __rtnl_newlink+0x1760/0x1760 [ 50.317545][ T3596] rtnetlink_rcv_msg+0x413/0xb80 [ 50.322631][ T3596] ? rtnl_newlink+0xa0/0xa0 [ 50.327159][ T3596] netlink_rcv_skb+0x153/0x420 [ 50.331931][ T3596] ? rtnl_newlink+0xa0/0xa0 [ 50.336436][ T3596] ? netlink_ack+0xa80/0xa80 [ 50.341095][ T3596] ? netlink_deliver_tap+0x1a2/0xc40 [ 50.346532][ T3596] ? netlink_deliver_tap+0x1b1/0xc40 [ 50.351839][ T3596] netlink_unicast+0x539/0x7e0 [ 50.356633][ T3596] ? netlink_attachskb+0x880/0x880 [ 50.361750][ T3596] ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70 [ 50.368003][ T3596] ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70 [ 50.374707][ T3596] ? __phys_addr_symbol+0x2c/0x70 [ 50.379753][ T3596] ? __sanitizer_cov_trace_cmp8+0x1d/0x70 [ 50.385568][ T3596] ? __check_object_size+0x16c/0x4f0 [ 50.390859][ T3596] netlink_sendmsg+0x904/0xe00 [ 50.395715][ T3596] ? netlink_unicast+0x7e0/0x7e0 [ 50.400722][ T3596] ? __sanitizer_cov_trace_const_cmp4+0x1c/0x70 [ 50.407003][ T3596] ? netlink_unicast+0x7e0/0x7e0 [ 50.412119][ T3596] sock_sendmsg+0xcf/0x120 [ 50.416548][ T3596] __sys_sendto+0x21c/0x320 [ 50.421052][ T3596] ? __ia32_sys_getpeername+0xb0/0xb0 [ 50.426427][ T3596] ? lockdep_hardirqs_on_prepare+0x400/0x400 [ 50.432721][ T3596] ? __context_tracking_exit+0xb8/0xe0 [ 50.438188][ T3596] ? lock_downgrade+0x6e0/0x6e0 [ 50.443041][ T3596] ? lock_downgrade+0x6e0/0x6e0 [ 50.447902][ T3596] __x64_sys_sendto+0xdd/0x1b0 [ 50.452759][ T3596] ? lockdep_hardirqs_on+0x79/0x100 [ 50.457964][ T3596] ? syscall_enter_from_user_mode+0x21/0x70 [ 50.464150][ T3596] do_syscall_64+0x35/0xb0 [ 50.468565][ T3596] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 50.474452][ T3596] RIP: 0033:0x7f3148504e1c [ 50.479052][ T3596] Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b [ 50.498926][ T3596] RSP: 002b:00007ffeab5f2ab0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 50.507342][ T3596] RAX: ffffffffffffffda RBX: 00007f314959d320 RCX: 00007f3148504e1c [ 50.515393][ T3596] RDX: 0000000000000048 RSI: 00007f314959d370 RDI: 0000000000000003 [ 50.523444][ T3596] RBP: 0000000000000000 R08: 00007ffeab5f2b04 R09: 000000000000000c [ 50.531492][ T3596] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 50.539455][ T3596] R13: 00007f314959d370 R14: 0000000000000003 R15: 0000000000000000 Fixes: 4acc45db7115 ("net: hsr: use hlist_head instead of list_head for mac addresses") Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Reported-and-tested-by: syzbot+f0eb4f3876de066b128c@syzkaller.appspotmail.com Signed-off-by: Juhee Kang <claudiajkang@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19atm: nicstar: Use kcalloc() to simplify codeChristophe JAILLET1-8/+2
Use kcalloc() instead of kmalloc_array() and a loop to set all the values of the array to NULL. While at it, remove a duplicated assignment to 'scq->num_entries'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19Merge branch 'dpaa2-eth-one-step-register'David S. Miller5-11/+106
Radu Bulie says: ==================== Provide direct access to 1588 one step register DPAA2 MAC supports 1588 one step timestamping. If this option is enabled then for each transmitted PTP event packet, the 1588 SINGLE_STEP register is accessed to modify the following fields: -offset of the correction field inside the PTP packet -UDP checksum update bit, in case the PTP event packet has UDP encapsulation These values can change any time, because there may be multiple PTP clients connected, that receive various 1588 frame types: - L2 only frame - UDP / Ipv4 - UDP / Ipv6 - other The current implementation uses dpni_set_single_step_cfg to update the SINLGE_STEP register. Using an MC command on the Tx datapath for each transmitted 1588 message introduces high delays, leading to low throughput and consequently to a small number of supported PTP clients. Besides these, the nanosecond correction field from the PTP packet will contain the high delay from the driver which together with the originTimestamp will render timestamp values that are unacceptable in a GM clock implementation. This patch series replaces the dpni_set_single_step_cfg function call from the Tx datapath for 1588 messages (when one step timestamping is enabled) with a callback that either implements direct access to the SINGLE_STEP register, eliminating the overhead caused by the MC command that will need to be dispatched by the MC firmware through the MC command portal interface or falls back to the dpni_set_single_step_cfg in case the MC version does not have support for returning the single step register base address. In other words all the delay introduced by dpni_set_single_step_cfg function will be eliminated (if MC version has support for returning the base address of the single step register), improving the egress driver performance for PTP packets when single step timestamping is enabled. The first patch adds a new attribute that contains the base address of the SINGLE_STEP register. It will be used to directly update the register on the Tx datapath. The second patch updates the driver such that the SINGLE_STEP register is either accessed directly if MC version >= 10.32 or is accessed through dpni_set_single_step_cfg command when 1588 messages are transmitted. Changes in v2: - move global function pointer into the driver's private structure in 2/2 - move repetitive code outside the body of the callback functions in 2/2 - update function dpaa2_ptp_onestep_reg_update_method and remove goto statement from non error path in 2/2 Changes in v3: - remove static storage class specifier from within the structure in 2/2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dpaa2-eth: Update SINGLE_STEP register accessRadu Bulie2-10/+93
DPAA2 MAC supports 1588 one step timestamping. If this option is enabled then for each transmitted PTP event packet, the 1588 SINGLE_STEP register is accessed to modify the following fields: -offset of the correction field inside the PTP packet -UDP checksum update bit, in case the PTP event packet has UDP encapsulation These values can change any time, because there may be multiple PTP clients connected, that receive various 1588 frame types: - L2 only frame - UDP / Ipv4 - UDP / Ipv6 - other The current implementation uses dpni_set_single_step_cfg to update the SINLGE_STEP register. Using an MC command on the Tx datapath for each transmitted 1588 message introduces high delays, leading to low throughput and consequently to a small number of supported PTP clients. Besides these, the nanosecond correction field from the PTP packet will contain the high delay from the driver which together with the originTimestamp will render timestamp values that are unacceptable in a GM clock implementation. This patch updates the Tx datapath for 1588 messages when single step timestamp is enabled and provides direct access to SINGLE_STEP register, eliminating the overhead caused by the dpni_set_single_step_cfg MC command. MC version >= 10.32 implements this functionality. If the MC version does not have support for returning the single step register base address, the driver will use dpni_set_single_step_cfg command for updates operations. All the delay introduced by dpni_set_single_step_cfg function will be eliminated (if MC version has support for returning the base address of the single step register), improving the egress driver performance for PTP packets when single step timestamping is enabled. Before these changes the maximum throughput for 1588 messages with single step hardware timestamp enabled was around 2000pps. After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dpaa2-eth: Update dpni_get_single_step_cfg commandRadu Bulie3-1/+13
dpni_get_single_step_cfg is an MC firmware command used for retrieving the contents of SINGLE_STEP 1588 register available in a DPMAC. This patch adds a new version of this command that returns as an extra argument the physical base address of the aforementioned register. The address will be used to directly modify the contents of the SINGLE_STEP register instead of invoking the MC command dpni_set_single_step_cgf. The former approach introduced huge delays on the TX datapath when one step PTP events were transmitted. This led to low throughput and high latencies observed in the PTP correction field. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: get rid of rtnl_lock_unregistering()Eric Dumazet1-42/+0
After recent patches, and in particular commits faab39f63c1f ("net: allow out-of-order netdev unregistration") and e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev") we no longer need the barrier implemented in rtnl_lock_unregistering(). Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: fix bridging with more than two member portsSvenning Sørensen1-3/+23
Commit b3612ccdf284 ("net: dsa: microchip: implement multi-bridge support") plugged a packet leak between ports that were members of different bridges. Unfortunately, this broke another use case, namely that of more than two ports that are members of the same bridge. After that commit, when a port is added to a bridge, hardware bridging between other member ports of that bridge will be cleared, preventing packet exchange between them. Fix by ensuring that the Port VLAN Membership bitmap includes any existing ports in the bridge, not just the port being added. Fixes: b3612ccdf284 ("net: dsa: microchip: implement multi-bridge support") Signed-off-by: Svenning Sørensen <sss@secomea.com> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: prestera: flower: fix destroy tmpl in chainVolodymyr Mytnyk1-9/+19
Fix flower destroy template callback to release template only for specific tc chain instead of all chain tempaltes. The issue was intruduced by previous commit that introduced multi-chain support. Fixes: fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19bridge: switch br_net_exit to batch modeEric Dumazet1-6/+9
cleanup_net() is competing with other rtnl users. Instead of calling br_net_exit() for each netns, call br_net_exit_batch() once. This gives cleanup_net() ability to group more devices and call unregister_netdevice_many() only once for all bridge devices. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Roopa Prabhu <roopa@nvidia.com> Cc: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19Merge branch 'mctp-i2c'David S. Miller5-0/+1190
Matt Johnston says: ==================== MCTP I2C driver This patch series adds a netdev driver providing MCTP transport over I2C. I think I've addressed all the points raised in v5. It now has mctp_i2c_unregister() to run things in the correct order, waiting for the worker thread and I2C rx to complete. Cheers, Matt -- v6: - Changed netdev register/unregister/free to avoid races. Ensure that netif functions are not used by irq handler/threads after unregister. - Fix incoming I2C hwaddr that was previously incorrect (left shifted 1 bit) - Add a check that byte_count wire header matches the length received - Renamed I2C driver to mctp-i2c-interface - Removed __func__ from print messages, added missing newlines - Removed sysfs mctp_current_mux file which was used for debug - Renamed curr_lock to sel_lock - Tidied comment formatting - Fix newline in Kconfig v5: - Fix incorrect format string v4: - Switch to __i2c_transfer() rather than __i2c_smbus_xfer(), drop 255 byte smbus patches - Use wait_event_idle() for the sleeping TX thread - Use dev_addr_set() v3: - Added Reviewed-bys for npcm7xx - Resend with net-next open v2: - Simpler Kconfig condition for i2c-mux dependency, from Randy Dunlap ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19mctp i2c: MCTP I2C binding driverMatt Johnston3-0/+1094
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) Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Wolfram Sang <wsa@kernel.org> # I2C transport parts Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dt-bindings: net: New binding mctp-i2c-controllerMatt Johnston2-0/+96
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> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: Force inlining of checksum functions in net/checksum.hChristophe Leroy1-23/+24
All functions defined as static inline in net/checksum.h are meant to be inlined for performance reason. But since commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") the compiler is allowed to uninline functions when it wants. Fair enough in the general case, but for tiny performance critical checksum helpers that's counter-productive. The problem mainly arises when selecting CONFIG_CC_OPTIMISE_FOR_SIZE, Those helpers being 'static inline' in header files you suddenly find them duplicated many times in the resulting vmlinux. Here is a typical exemple when building powerpc pmac32_defconfig with CONFIG_CC_OPTIMISE_FOR_SIZE. csum_sub() appears 4 times: c04a23cc <csum_sub>: c04a23cc: 7c 84 20 f8 not r4,r4 c04a23d0: 7c 63 20 14 addc r3,r3,r4 c04a23d4: 7c 63 01 94 addze r3,r3 c04a23d8: 4e 80 00 20 blr ... c04a2ce8: 4b ff f6 e5 bl c04a23cc <csum_sub> ... c04a2d2c: 4b ff f6 a1 bl c04a23cc <csum_sub> ... c04a2d54: 4b ff f6 79 bl c04a23cc <csum_sub> ... c04a754c <csum_sub>: c04a754c: 7c 84 20 f8 not r4,r4 c04a7550: 7c 63 20 14 addc r3,r3,r4 c04a7554: 7c 63 01 94 addze r3,r3 c04a7558: 4e 80 00 20 blr ... c04ac930: 4b ff ac 1d bl c04a754c <csum_sub> ... c04ad264: 4b ff a2 e9 bl c04a754c <csum_sub> ... c04e3b08 <csum_sub>: c04e3b08: 7c 84 20 f8 not r4,r4 c04e3b0c: 7c 63 20 14 addc r3,r3,r4 c04e3b10: 7c 63 01 94 addze r3,r3 c04e3b14: 4e 80 00 20 blr ... c04e5788: 4b ff e3 81 bl c04e3b08 <csum_sub> ... c04e65c8: 4b ff d5 41 bl c04e3b08 <csum_sub> ... c0512d34 <csum_sub>: c0512d34: 7c 84 20 f8 not r4,r4 c0512d38: 7c 63 20 14 addc r3,r3,r4 c0512d3c: 7c 63 01 94 addze r3,r3 c0512d40: 4e 80 00 20 blr ... c0512dfc: 4b ff ff 39 bl c0512d34 <csum_sub> ... c05138bc: 4b ff f4 79 bl c0512d34 <csum_sub> ... Restore the expected behaviour by using __always_inline for all functions defined in net/checksum.h vmlinux size is even reduced by 256 bytes with this patch: text data bss dec hex filename 6980022 2515362 194384 9689768 93daa8 vmlinux.before 6979862 2515266 194384 9689512 93d9a8 vmlinux.now Fixes: ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: ip6mr: add support for passing full packet on wrong mifMobashshera Rasool2-4/+15
This patch adds support for MRT6MSG_WRMIFWHOLE which is used to pass full packet and real vif id when the incoming interface is wrong. While the RP and FHR are setting up state we need to be sending the registers encapsulated with all the data inside otherwise we lose it. The RP then decapsulates it and forwards it to the interested parties. Currently with WRONGMIF we can only be sending empty register packets and will lose that data. This behaviour can be enabled by using MRT_PIM with val == MRT6MSG_WRMIFWHOLE. This doesn't prevent MRT6MSG_WRONGMIF from happening, it happens in addition to it, also it is controlled by the same throttling parameters as WRONGMIF (i.e. 1 packet per 3 seconds currently). Both messages are generated to keep backwards compatibily and avoid breaking someone who was enabling MRT_PIM with val == 4, since any positive val is accepted and treated the same. Signed-off-by: Mobashshera Rasool <mobash.rasool.linux@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19x86/mce: Work around an erratum on fast string copy instructionsJue Wang2-1/+68
A rare kernel panic scenario can happen when the following conditions are met due to an erratum on fast string copy instructions: 1) An uncorrected error. 2) That error must be in first cache line of a page. 3) Kernel must execute page_copy from the page immediately before that page. The fast string copy instructions ("REP; MOVS*") could consume an uncorrectable memory error in the cache line _right after_ the desired region to copy and raise an MCE. Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string copy and will avoid such spurious machine checks. However, that is less preferable due to the permanent performance impact. Considering memory poison is rare, it's desirable to keep fast string copy enabled until an MCE is seen. Intel has confirmed the following: 1. The CPU erratum of fast string copy only applies to Skylake, Cascade Lake and Cooper Lake generations. Directly return from the MCE handler: 2. Will result in complete execution of the "REP; MOVS*" with no data loss or corruption. 3. Will not result in another MCE firing on the next poisoned cache line due to "REP; MOVS*". 4. Will resume execution from a correct point in code. 5. Will result in the same instruction that triggered the MCE firing a second MCE immediately for any other software recoverable data fetch errors. 6. Is not safe without disabling the fast string copy, as the next fast string copy of the same buffer on the same CPU would result in a PANIC MCE. This should mitigate the erratum completely with the only caveat that the fast string copy is disabled on the affected hyper thread thus performance degradation. This is still better than the OS crashing on MCEs raised on an irrelevant process due to "REP; MOVS*' accesses in a kernel context, e.g., copy_page. Tested: Injected errors on 1st cache line of 8 anonymous pages of process 'proc1' and observed MCE consumption from 'proc2' with no panic (directly returned). Without the fix, the host panicked within a few minutes on a random 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ] Signed-off-by: Jue Wang <juew@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20220218013209.2436006-1-juew@google.com
2022-02-19Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueDavid S. Miller9-23/+39
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-02-18 This series contains updates to ice driver only. Wojciech fixes protocol matching for slow-path switchdev so that all packets are correctly redirected. Michal removes accidental unconditional setting of l4 port filtering flag. Jake adds locking to protect VF reset and removal to fix various issues that can be encountered when they race with each other. Tom Rix propagates an error and initializes a struct to resolve reported Clang issues. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19i40e: remove dead stores on XSK hotpathAlexander Lobakin1-2/+1
The 'if (ntu == rx_ring->count)' block in i40e_alloc_rx_buffers_zc() was previously residing in the loop, but after introducing the batched interface it is used only to wrap-around the NTU descriptor, thus no more need to assign 'xdp'. 'cleaned_count' in i40e_clean_rx_irq_zc() was previously being incremented in the loop, but after commit f12738b6ec06 ("i40e: remove unnecessary cleaned_count updates") it gets assigned only once after it, so the initialization can be dropped. Fixes: 6aab0bb0c5cd ("i40e: Use the xsk batched rx allocation interface") Fixes: f12738b6ec06 ("i40e: remove unnecessary cleaned_count updates") Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.