- 14 May, 2020 40 commits
-
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 45491133 upstream. When port is put into LISTENING state it shouldn't populate the FDB, so set the port's STP state in hardware to DISCARDING instead of LEARNING. It will therefore keep listening to BPDU packets, but discard other non-control packets and won't perform any learning. Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9cb026eb upstream. When STP state is set to DISABLED the port is assumed to be inactive, but currently we forward packets ingressing through it. Instead, set the port's STP state in hardware to DISCARDING, which means it doesn't forward packets or perform any learning, but it does trap control packets. However, these packets will be dropped by bridge code, which results in the expected behavior. Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by:
-
Honggang Li authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0de4cbb3 upstream. [ 598.852037] ------------[ cut here ]------------ [ 598.856698] WARNING: at lib/dma-debug.c:887 check_unmap+0xf8/0x920() [ 598.863079] cxgb3 0000:01:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x0000000003310000] [map size=17 bytes] [unmap size=16 bytes] [ 598.878265] Modules linked in: xprtrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad kvm_amd kvm ipmi_devintf ipmi_ssif dcdbas pcspkr ipmi_si sg ipmi_msghandler acpi_power_meter amd64_edac_mod shpchp edac_core sp5100_tco k10temp edac_mce_amd i2c_piix4 acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common ata_generic iw_cxgb3 pata_acpi ib_core ib_addr mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm pata_atiixp drm ahci libahci serio_raw i2c_core cxgb3 libata bnx2 mdio dm_mirror dm_region_hash dm_log dm_mod [ 598.946822] CPU: 3 PID: 11820 Comm: cmtime Not tainted 3.10.0-327.el7.x86_64.debug #1 [ 598.954681] Hardware name: Dell Inc. PowerEdge R415/0GXH08, BIOS 2.0.2 10/22/2012 [ 598.962193] ffff8808077479a8 000000000381a432 ffff880807747960 ffffffff81700918 [ 598.969663] ffff880807747998 ffffffff8108b6c0 ffff880807747a80 ffff8808063f55c0 [ 598.977132] ffffffff833ca850 0000000000000282 ffff88080b1bb800 ffff880807747a00 [ 598.984602] Call Trace: [ 598.987062] [<ffffffff81700918>] dump_stack+0x19/0x1b [ 598.992224] [<ffffffff8108b6c0>] warn_slowpath_common+0x70/0xb0 [ 598.998254] [<ffffffff8108b75c>] warn_slowpath_fmt+0x5c/0x80 [ 599.004033] [<ffffffff813903b8>] check_unmap+0xf8/0x920 [ 599.009369] [<ffffffff81025959>] ? sched_clock+0x9/0x10 [ 599.014702] [<ffffffff81390cee>] debug_dma_free_coherent+0x7e/0xa0 [ 599.021008] [<ffffffffa01ece2c>] cxio_destroy_cq+0xcc/0x160 [iw_cxgb3] [ 599.027654] [<ffffffffa01e8da0>] iwch_destroy_cq+0xf0/0x140 [iw_cxgb3] [ 599.034307] [<ffffffffa01c4bfe>] ib_destroy_cq+0x1e/0x30 [ib_core] [ 599.040601] [<ffffffffa04ff2d2>] ib_uverbs_close+0x302/0x4d0 [ib_uverbs] [ 599.047417] [<ffffffff812335a2>] __fput+0x102/0x310 [ 599.052401] [<ffffffff8123388e>] ____fput+0xe/0x10 [ 599.057297] [<ffffffff810bbde4>] task_work_run+0xb4/0xe0 [ 599.062719] [<ffffffff81092a84>] do_exit+0x304/0xc60 [ 599.067789] [<ffffffff81025905>] ? native_sched_clock+0x35/0x80 [ 599.073820] [<ffffffff81025959>] ? sched_clock+0x9/0x10 [ 599.079153] [<ffffffff8170a49c>] ? _raw_spin_unlock_irq+0x2c/0x50 [ 599.085358] [<ffffffff8109346c>] do_group_exit+0x4c/0xc0 [ 599.090779] [<ffffffff810a8661>] get_signal_to_deliver+0x2e1/0x960 [ 599.097071] [<ffffffff8101c497>] do_signal+0x57/0x6e0 [ 599.102229] [<ffffffff81714bd1>] ? sysret_signal+0x5/0x4e [ 599.107738] [<ffffffff8101cb7f>] do_notify_resume+0x5f/0xb0 [ 599.113418] [<ffffffff81714e7d>] int_signal+0x12/0x17 [ 599.118576] ---[ end trace 1e4653102e7e7019 ]--- [ 599.123211] Mapped at: [ 599.125577] [<ffffffff8138ed8b>] debug_dma_alloc_coherent+0x2b/0x80 [ 599.131968] [<ffffffffa01ec862>] cxio_create_cq+0xf2/0x1f0 [iw_cxgb3] [ 599.139920] [<ffffffffa01e9c05>] iwch_create_cq+0x105/0x4e0 [iw_cxgb3] [ 599.147895] [<ffffffffa0500584>] create_cq.constprop.14+0x184/0x2e0 [ib_uverbs] [ 599.156649] [<ffffffffa05027fb>] ib_uverbs_create_cq+0x10b/0x140 [ib_uverbs] Fixes: b955150e ('RDMA/cxgb3: When a user QP is marked in error, also mark the CQs in error') Signed-off-by:
Honggang Li <honli@redhat.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Reviewed-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9f74660b upstream. Some NFSv4.1 OPEN requests were hanging waiting for the NFS server to finish recalling delegations. Turns out that each NFSv4.1 CB request on RDMA gets a GARBAGE_ARGS reply from the Linux client. Commit 756b9b37 added a line in bc_svc_process that overwrites the incoming rq_rcv_buf's length with the value in rq_private_buf.len. But rpcrdma_bc_receive_call() does not invoke xprt_complete_bc_request(), thus rq_private_buf.len is not initialized. svc_process_common() is invoked with a zero-length RPC message, and fails. Fixes: 756b9b37 ('SUNRPC: Fix callback channel') Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ffc4d9b1 upstream. Preserve any rpcrdma_req that is attached to rpc_rqst's allocated for the backchannel. Otherwise, after all the pre-allocated backchannel req's are consumed, incoming backward calls start writing on freed memory. Somehow this hunk got lost. Fixes: f531a5db ('xprtrdma: Pre-allocate backward rpc_rqst') Signed-off-by:
Devesh Sharma <devesh.sharma@avagotech.com> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9b06688b upstream. Clean up. rb_lock critical sections added in rpcrdma_ep_post_extra_recv() should have first been converted to use normal spin_lock now that the reply handler is a work queue. The backchannel set up code should use the appropriate helper instead of open-coding a rb_recv_bufs list add. Problem introduced by glib patch re-ordering on my part. Fixes: f531a5db ('xprtrdma: Pre-allocate backward rpc_rqst') Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit abfb6897 upstream. The rpcrdma_create_req() function returns error pointers or success. It never returns NULL. Fixes: f531a5db ('xprtrdma: Pre-allocate backward rpc_rqst and send/receive buffers') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Raja Mani authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b9c191be upstream. ath10k_core_probe_fw() simply returns error without freeing cached firmware file content when get board id operation fails. Free cached fw bin data in failure case to avoid memory leak. Fixes: db0984e5 ("ath10k: select board data based on BMI chip id and board id") Signed-off-by:
Raja Mani <rmani@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Boris Brezillon authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit de64aa9e upstream. src_ssync_features field is only 1 byte large, and the 4th reserved area is actually 8 bytes large. Fixes: d1e1f4e4 ("mtd: nand: add support for reading ONFI parameters from NAND device") Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f87fda00 upstream. ether_addr_equal_64bits() requires some care about its arguments, namely that 8 bytes might be read, even if last 2 byte values are not used. KASan detected a violation with null_mac_addr and lacpdu_mcast_addr in bond_3ad.c Same problem with mac_bcast[] and mac_v6_allmcast[] in bond_alb.c : Although the 8-byte alignment was there, KASan would detect out of bound accesses. Fixes: 815117ad ("bonding: use ether_addr_equal_unaligned for bond addr compare") Fixes: bb54e589 ("bonding: Verify RX LACPDU has proper dest mac-addr") Fixes: 885a136c ("bonding: use compare_ether_addr_64bits() in ALB") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Ding Tianhong <dingtianhong@huawei.com> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 17ae1c65 upstream. Make sure to drop the reference taken by bus_find_device_by_name() before returning from phy_connect() and phy_attach(). Note that both function still take a reference to the phy device through phy_attach_direct(). Fixes: e1393456 ("[PATCH] PHY Layer fixup") Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
phil.turnbull@oracle.com authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8ab86c00 upstream. skb is not freed if newsk is NULL. Rework the error path so free_skb is unconditionally called on function exit. Fixes: c3ea9fa2 ("[IrDA] af_irda: IRDA_ASSERT cleanups") Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Signed-off-by:
-
Jiri Kosina authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 838fe188 upstream. cleaner_kthread() is not marked freezable, and therefore calling try_to_freeze() in its context is a pointless no-op. In addition to that, as has been clearly demonstrated by 80ad623e ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"), it's perfectly valid / legal for cleaner_kthread() to stay scheduled out in an arbitrary place during suspend (in that particular example that was waiting for reading of extent pages), so there is no need to leave any traces of freezer in this kthread. Fixes: 80ad623e ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()") Fixes: 69624913 ("btrfs: clear PF_NOFREEZE in cleaner_kthread()") Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8d5958f4 upstream. Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 3d4357fb upstream. Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2ed5c3f0 upstream. Reported-by:
Stas Nichiporovich <stasn77@gmail.com> Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6529d75a upstream. We need to update backlog too when we update qlen. Joint work with Stas. Reported-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 357cc9b4 upstream. hfsc updates backlog lazily, that is only when we dump the stats. This is problematic after we begin to update backlog in qdisc_tree_reduce_backlog(). Reported-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6a73b571 upstream. Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
WANG Cong authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a27758ff upstream. For gso_skb we only update qlen, backlog should be updated too. Note, it is correct to just update these stats at one layer, because the gso_skb is cached there. Reported-by:
-
Matthew Finlay authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e3a19b53 upstream. ConnectX4-Lx uses an inline wqe mode that currently defaults to requiring the entire L2 header be included in the wqe. This patch fixes mlx5e_get_inline_hdr_size() to account for all L2 headers (VLAN, QinQ, etc) using skb_network_offset(skb). Fixes: e586b3b0 ("net/mlx5: Ethernet Datapath files") Signed-off-by:
Matthew Finlay <matt@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Mohamad Haj Yahia authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1061c90f upstream. When PCI error is detected we should save the state of the pci prior to disabling it. Also when receiving pci slot reset call we need to verify that the device is responsive. Fixes: 89d44f0a ('net/mlx5_core: Add pci error handlers to mlx5_core driver') Signed-off-by:
Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by:
-
Mohamad Haj Yahia authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 65ee6708 upstream. The current implementation does not handle timeout in case of command with callback request, and this can lead to deadlock if the command doesn't get fw response. Add delayed callback timeout work before posting the command to fw. In case of real fw command completion we will cancel the delayed work. In case of fw command timeout the callback timeout handler will be called and it will simulate fw completion with timeout error. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Mohamad Haj Yahia authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9cba4ebc upstream. Call command completion handler in case of timeout when working in interrupts mode. Avoid flushing the commands workqueue after acquiring the semaphores to prevent a potential deadlock. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Daniel Jurgens authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d57847dc upstream. The device ID for VFs is in a different location than PFs. This results in the poll always timing out for VFs. There's no good way to read the VF device ID without using the PF's configuration space. Switch to waiting for the health poll to start incrementing. Also remove the 1s sleep at the beginning. fixes: 89d44f0a ('net/mlx5_core: Add pci error handlers to mlx5_core driver') Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Mohamad Haj Yahia authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c1d4d2e9 upstream. In internal error state the health poll thread will eventually call synchronize_irq() (to safely trigger command completions) which might sleep, so we are calling sleeping function from atomic context which is invalid. Here we move trigger_cmd_completions(dev) to enter error state which is the earliest stage in error state handling. This way we won't need to wait for next health poll to trigger command completions and will solve the scheduling while atomic issue. mlx5_enter_error_state can be called from two contexts, protect it with dev->intf_state_lock Fixes: 89d44f0a ('net/mlx5_core: Add pci error handlers to mlx5_core driver') Signed-off-by:
-
Wang Sheng-Hui authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f299a02d upstream. Commit 311c7c71 ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node") introduced mlx5_*_alloc_node() but missed changing some calling and warn messages. This patch introduces 2 changes: * Use mlx5_buf_alloc_node() instead of mlx5_buf_alloc() in mlx5_wq_ll_create() * Update the failure warn messages with _node postfix for mlx5_*_alloc function names Fixes: 311c7c71 ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node") Signed-off-by:
Wang Sheng-Hui <shhuiw@foxmail.com> Acked-By:
-
Eli Cohen authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0ca00fc1 upstream. Blue flame is a latency enhancement feature that allows the driver to write the packet data directly to the NIC's registers thus making the read of the packet data from host memory redundant. We maintain a quota for the blue flame which is reloaded whenever we identify that the hardware is processing send requests and processes them fast enough so by the time we post the next send request it was able to process all the pending ones. This indicates that the hardware is capable of processing more blue flame requests efficiently. The blue flame quota is decremented whenever we send using blue flame. The current code erroneously clears the budget if we did not use blue flame for the current post send operation and we fix it here. Fixes: 88a85f99 ('net/mlx5e: TX latency optimization to save DMA reads') Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Majd Dibbiny authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9cd3411c upstream. Mask the reserved bits when reading the number of newly created XRCD. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Signed-off-by:
-
Majd Dibbiny authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 418f8399 upstream. Add 16 reserved bytes at the end of mlx5_modify_qp_mbox_in to match the hardware spec definition. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Rana Shahout authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6e4c2189 upstream. Bit 25 of eth_proto_capability in PTYS register is 1000Base-TT and not 100Base-T. Fixes: f62b8bb8 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by:
Rana Shahout <ranas@mellanox.com> Signed-off-by:
-
Eran Ben Elisha authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c0fcebf5 upstream. Add a 4-digit padding to show FW version in proper format. Fixes: 9603b61d ('mlx5: Move pci device handling from...') Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Or Gerlitz authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b6c07bd upstream. The command timeout is terribly long, whole two hours. Make it 60s so if things do go wrong, the user gets feedback in relatively short time, so they can take corrective actions and/or investigate using tools and such. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Leon Romanovsky authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 75c1657e upstream. Fix the RC QPs send queue overhead computation to take into account two additional segments in the WQE which are needed for registration operations. The ATOMIC and UMR segments can't coexist together, so chose maximum out of them. The commit 9e65dc37 ("IB/mlx5: Fix RC transport send queue overhead computation") was intended to update RC transport as commit messages states, but added the code to UC transport. Fixes: 9e65dc37 ("IB/mlx5: Fix RC transport send queue overhead computation") Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
-
Noa Osherovich authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b276190 upstream. Currently the firmware can't work with a page with dma address 0. Passing such an address to the firmware will cause the give_pages command to fail. To avoid this, in case we get a 0 dma address of a page from the dma engine, we avoid passing it to FW by remapping to get an address other than 0. Fixes: bf0bf77f ('mlx5: Support communicating arbitrary host...') Signed-off-by:
-
Peter Griffin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c23ac90f upstream. c8sectpfe driver relied on CONFIG_FW_LOADER_USER_HELPER_FALLBACK option for loading its xp70 firmware. A previous commit removed this Kconfig option, as it is apparently harmful, but did not update the driver code which relied on it. This patch reworks the firmware loading into the start_feed callback. At this point we can be sure the rootfs is present, thereby removing the depedency on CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Fixes: 79f5b6ae ('[media] c8sectpfe: Remove select on CONFIG_FW_LOADER_USER_HELPER_FALLBACK') Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Brian Norris authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 715780ae upstream. The kerneldoc for request_firmware_nowait() says that it may call the provided cont() callback with @fw == NULL, if the firmware request fails. However, this is not the case when called with an empty string (""). This case is short-circuited by the 'name[0] == '\0'' check introduced in commit 471b095d ("firmware_class: make sure fw requests contain a name"), so _request_firmware() never gets to set the fw to NULL. Noticed while using the new 'trigger_async_request' testing hook: # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [10553.726178] test_firmware: loading '' [10553.729859] test_firmware: loaded: 995209091 # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [10733.676184] test_firmware: loading '' [10733.679855] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [10733.687951] pgd = ec188000 [10733.690655] [00000004] *pgd=00000000 [10733.694240] Internal error: Oops: 5 [#1] SMP ARM [10733.698847] Modules linked in: btmrvl_sdio btmrvl bluetooth sbs_battery nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables asix usbnet mwifiex_sdio mwifiex cfg80211 jitterentropy_rng drbg joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun [10733.725670] CPU: 0 PID: 6600 Comm: bash Not tainted 4.4.0-rc4-00351-g63d0877 #178 [10733.733137] Hardware name: Rockchip (Device Tree) [10733.737831] task: ed24f6c0 ti: ee322000 task.ti: ee322000 [10733.743222] PC is at do_raw_spin_lock+0x18/0x1a0 [10733.747831] LR is at _raw_spin_lock+0x18/0x1c [10733.752180] pc : [<c00653a0>] lr : [<c054c204>] psr: a00d0013 [10733.752180] sp : ee323df8 ip : ee323e20 fp : ee323e1c [10733.763634] r10: 00000051 r9 : b6f18000 r8 : ee323f80 [10733.768847] r7 : c089cebc r6 : 00000001 r5 : 00000000 r4 : ec0e6000 [10733.775360] r3 : dead4ead r2 : c06bd140 r1 : eef913b4 r0 : 00000000 [10733.781874] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [10733.788995] Control: 10c5387d Table: 2c18806a DAC: 00000051 [10733.794728] Process bash (pid: 6600, stack limit = 0xee322218) [10733.800549] Stack: (0xee323df8 to 0xee324000) [10733.804896] 3de0: ec0e6000 00000000 [10733.813059] 3e00: 00000001 c089cebc ee323f80 b6f18000 ee323e2c ee323e20 c054c204 c0065394 [10733.821221] 3e20: ee323e44 ee323e30 c02fec60 c054c1f8 ec0e7ec0 ec3fcfc0 ee323e5c ee323e48 [10733.829384] 3e40: c02fed08 c02fec48 c07dbf74 eeb05a00 ee323e8c ee323e60 c0253828 c02fecac [10733.837547] 3e60: 00000001 c0116950 ee323eac ee323e78 00000001 ec3fce00 ed2d9700 ed2d970c [10733.845710] 3e80: ee323e9c ee323e90 c02e873c c02537d4 ee323eac ee323ea0 c017bd40 c02e8720 [10733.853873] 3ea0: ee323ee4 ee323eb0 c017b250 c017bd00 00000000 00000000 f3e47a54 ec128b00 [10733.862035] 3ec0: c017b10c ee323f80 00000001 c000f504 ee322000 00000000 ee323f4c ee323ee8 [10733.870197] 3ee0: c011b71c c017b118 ee323fb0 c011bc90 becfa8d9 00000001 ec128b00 00000001 [10733.878359] 3f00: b6f18000 ee323f80 ee323f4c ee323f18 c011bc90 c0063950 ee323f3c ee323f28 [10733.886522] 3f20: c0063950 c0549138 00000001 ec128b00 00000001 ec128b00 b6f18000 ee323f80 [10733.894684] 3f40: ee323f7c ee323f50 c011bed8 c011b6ec c0135fb8 c0135f24 ec128b00 ec128b00 [10733.902847] 3f60: 00000001 b6f18000 c000f504 ee322000 ee323fa4 ee323f80 c011c664 c011be24 [10733.911009] 3f80: 00000000 00000000 00000001 b6f18000 b6e79be0 00000004 00000000 ee323fa8 [10733.919172] 3fa0: c000f340 c011c618 00000001 b6f18000 00000001 b6f18000 00000001 00000000 [10733.927334] 3fc0: 00000001 b6f18000 b6e79be0 00000004 00000001 00000001 8068a3f1 b6e79c84 [10733.935496] 3fe0: 00000000 becfa7dc b6de194d b6e20246 400d0030 00000001 7a4536e8 49bda390 [10733.943664] [<c00653a0>] (do_raw_spin_lock) from [<c054c204>] (_raw_spin_lock+0x18/0x1c) [10733.951743] [<c054c204>] (_raw_spin_lock) from [<c02fec60>] (fw_free_buf+0x24/0x64) [10733.959388] [<c02fec60>] (fw_free_buf) from [<c02fed08>] (release_firmware+0x68/0x74) [10733.967207] [<c02fed08>] (release_firmware) from [<c0253828>] (trigger_async_request_store+0x60/0x124) [10733.976501] [<c0253828>] (trigger_async_request_store) from [<c02e873c>] (dev_attr_store+0x28/0x34) [10733.985533] [<c02e873c>] (dev_attr_store) from [<c017bd40>] (sysfs_kf_write+0x4c/0x58) [10733.993437] [<c017bd40>] (sysfs_kf_write) from [<c017b250>] (kernfs_fop_write+0x144/0x1a8) [10734.001689] [<c017b250>] (kernfs_fop_write) from [<c011b71c>] (__vfs_write+0x3c/0xe4) After this patch: # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [ 32.126322] test_firmware: loading '' [ 32.129995] test_firmware: failed to async load firmware -bash: printf: write error: No such device Fixes: 471b095d ("firmware_class: make sure fw requests contain a name") Signed-off-by:
Ming Lei <ming.lei@canonical.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Alexey Kardashevskiy authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit dead1c84 upstream. The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing which reads "assigned-addresses" of every PCI device and initializes the device resources. However if the property is missing or zero sized, then there is no fallback of any kind and the PCI resources remain undiscovered, i.e. pdev->resource[] array remains empty. This adds a fallback which parses the "reg" property in pretty much same way except it marks resources as "unset" which later make Linux assign those resources proper addresses. This has an effect when: 1. a hypervisor failed to assign any resource for a device; 2. /chosen/linux,pci-probe-only=0 is in the DT so the system may try assigning a resource. Neither is likely to happen under PowerVM. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Alexander Duyck authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a0ca153f upstream. This patch fixes an issue I found in which we were dropping frames if we had enabled checksums on GRE headers that were encapsulated by either FOU or GUE. Without this patch I was barely able to get 1 Gb/s of throughput. With this patch applied I am now at least getting around 6 Gb/s. The issue is due to the fact that with FOU or GUE applied we do not provide a transport offset pointing to the GRE header, nor do we offload it in software as the GRE header is completely skipped by GSO and treated like a VXLAN or GENEVE type header. As such we need to prevent the stack from generating it and also prevent GRE from generating it via any interface we create. Fixes: c3483384 ("gro: Allow tunnel stacking in the case of FOU/GUE") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Matan Barak authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4e408167 upstream. Hop limit value wasn't copied from attributes when ah was created. This may influence packets for unconnected services to get dropped in routers when endpoints are not in the same subnet. Fixes: fa417f7b ("IB/mlx4: Add support for IBoE") Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
