| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Clear DMA ops when switching domain
Since commit 08a27c1c3ecf ("iommu: Add support to change default domain
of an iommu group") a user can switch a device between IOMMU and direct
DMA through sysfs. This doesn't work for AMD IOMMU at the moment because
dev->dma_ops is not cleared when switching from a DMA to an identity
IOMMU domain. The DMA layer thus attempts to use the dma-iommu ops on an
identity domain, causing an oops:
# echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/unbind
# echo identity > /sys/bus/pci/devices/0000:00:05.0/iommu_group/type
# echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/bind
...
BUG: kernel NULL pointer dereference, address: 0000000000000028
...
Call Trace:
iommu_dma_alloc
e1000e_setup_tx_resources
e1000e_open
Since iommu_change_dev_def_domain() calls probe_finalize() again, clear
the dma_ops there like Vt-d does. |
| In the Linux kernel, the following vulnerability has been resolved:
efi/fdt: fix panic when no valid fdt found
setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no
valid fdt found then initial_boot_params will be null. So we
should stop further fdt processing here. I encountered this
issue on risc-v. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: track AF_XDP ZC enabled queues in bitmap
Commit c7a219048e45 ("ice: Remove xsk_buff_pool from VSI structure")
silently introduced a regression and broke the Tx side of AF_XDP in copy
mode. xsk_pool on ice_ring is set only based on the existence of the XDP
prog on the VSI which in turn picks ice_clean_tx_irq_zc to be executed.
That is not something that should happen for copy mode as it should use
the regular data path ice_clean_tx_irq.
This results in a following splat when xdpsock is run in txonly or l2fwd
scenarios in copy mode:
<snip>
[ 106.050195] BUG: kernel NULL pointer dereference, address: 0000000000000030
[ 106.057269] #PF: supervisor read access in kernel mode
[ 106.062493] #PF: error_code(0x0000) - not-present page
[ 106.067709] PGD 0 P4D 0
[ 106.070293] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 106.074721] CPU: 61 PID: 0 Comm: swapper/61 Not tainted 5.12.0-rc2+ #45
[ 106.081436] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 106.092027] RIP: 0010:xp_raw_get_dma+0x36/0x50
[ 106.096551] Code: 74 14 48 b8 ff ff ff ff ff ff 00 00 48 21 f0 48 c1 ee 30 48 01 c6 48 8b 87 90 00 00 00 48 89 f2 81 e6 ff 0f 00 00 48 c1 ea 0c <48> 8b 04 d0 48 83 e0 fe 48 01 f0 c3 66 66 2e 0f 1f 84 00 00 00 00
[ 106.115588] RSP: 0018:ffffc9000d694e50 EFLAGS: 00010206
[ 106.120893] RAX: 0000000000000000 RBX: ffff88984b8c8a00 RCX: ffff889852581800
[ 106.128137] RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffff88984cd8b800
[ 106.135383] RBP: ffff888123b50001 R08: ffff889896800000 R09: 0000000000000800
[ 106.142628] R10: 0000000000000000 R11: ffffffff826060c0 R12: 00000000000000ff
[ 106.149872] R13: 0000000000000000 R14: 0000000000000040 R15: ffff888123b50018
[ 106.157117] FS: 0000000000000000(0000) GS:ffff8897e0f40000(0000) knlGS:0000000000000000
[ 106.165332] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 106.171163] CR2: 0000000000000030 CR3: 000000000560a004 CR4: 00000000007706e0
[ 106.178408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 106.185653] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 106.192898] PKRU: 55555554
[ 106.195653] Call Trace:
[ 106.198143] <IRQ>
[ 106.200196] ice_clean_tx_irq_zc+0x183/0x2a0 [ice]
[ 106.205087] ice_napi_poll+0x3e/0x590 [ice]
[ 106.209356] __napi_poll+0x2a/0x160
[ 106.212911] net_rx_action+0xd6/0x200
[ 106.216634] __do_softirq+0xbf/0x29b
[ 106.220274] irq_exit_rcu+0x88/0xc0
[ 106.223819] common_interrupt+0x7b/0xa0
[ 106.227719] </IRQ>
[ 106.229857] asm_common_interrupt+0x1e/0x40
</snip>
Fix this by introducing the bitmap of queues that are zero-copy enabled,
where each bit, corresponding to a queue id that xsk pool is being
configured on, will be set/cleared within ice_xsk_pool_{en,dis}able and
checked within ice_xsk_pool(). The latter is a function used for
deciding which napi poll routine is executed.
Idea is being taken from our other drivers such as i40e and ixgbe. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: fix NULL-deref on disconnect
Commit 9d7b18668956 ("HID: magicmouse: add support for Apple Magic
Trackpad 2") added a sanity check for an Apple trackpad but returned
success instead of -ENODEV when the check failed. This means that the
remove callback will dereference the never-initialised driver data
pointer when the driver is later unbound (e.g. on USB disconnect). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
In commit 41ca9caaae0b
("drm/mediatek: hdmi: Add check for CEA modes only") a check
for CEA modes was added to function mtk_hdmi_bridge_mode_valid()
in order to address possible issues on MT8167;
moreover, with commit c91026a938c2
("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock")
another similar check was introduced.
Unfortunately though, at the time of writing, MT8173 does not provide
any mtk_hdmi_conf structure and this is crashing the kernel with NULL
pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as
soon as a HDMI cable gets plugged in.
To fix this regression, add a NULL pointer check for hdmi->conf in the
said function, restoring HDMI functionality and avoiding NULL pointer
kernel panics. |
| In the Linux kernel, the following vulnerability has been resolved:
ipmi: ssif: initialize ssif_info->client early
During probe ssif_info->client is dereferenced in error path. However,
it is set when some of the error checking has already been done. This
causes following kernel crash if an error path is taken:
[ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present
[ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
...
[ 30.657723][ T674] pc : __dev_printk+0x28/0xa0
[ 30.657732][ T674] lr : _dev_err+0x7c/0xa0
...
[ 30.657772][ T674] Call trace:
[ 30.657775][ T674] __dev_printk+0x28/0xa0
[ 30.657778][ T674] _dev_err+0x7c/0xa0
[ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]
[ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0
...
Initialize ssif_info->client before any error path can be taken. Clear
i2c_client data in the error path to prevent the dangling pointer from
leaking. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ideapad-laptop: fix a NULL pointer dereference
The third parameter of dytc_cql_command should not be NULL since it will
be dereferenced immediately. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Add pointer checks in qedf_update_link_speed()
The following trace was observed:
[ 14.042059] Call Trace:
[ 14.042061] <IRQ>
[ 14.042068] qedf_link_update+0x144/0x1f0 [qedf]
[ 14.042117] qed_link_update+0x5c/0x80 [qed]
[ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed]
[ 14.042155] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042170] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042186] ? qed_rd+0x13/0x40 [qed]
[ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed]
[ 14.042221] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed]
[ 14.042245] tasklet_action_common.isra.14+0x5a/0x100
[ 14.042250] __do_softirq+0xe4/0x2f8
[ 14.042253] irq_exit+0xf7/0x100
[ 14.042255] do_IRQ+0x7f/0xd0
[ 14.042257] common_interrupt+0xf/0xf
[ 14.042259] </IRQ>
API qedf_link_update() is getting called from QED but by that time
shost_data is not initialised. This results in a NULL pointer dereference
when we try to dereference shost_data while updating supported_speeds.
Add a NULL pointer check before dereferencing shost_data. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Use online_vcpus, not created_vcpus, to iterate over vCPUs
Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting
VMSAs for SEV, which effectively switches to use online_vcpus instead of
created_vcpus. This fixes a possible null-pointer dereference as
created_vcpus does not guarantee a vCPU exists, since it is updated at
the very beginning of KVM_CREATE_VCPU. created_vcpus exists to allow the
bulk of vCPU creation to run in parallel, while still correctly
restricting the max number of max vCPUs. |
| In the Linux kernel, the following vulnerability has been resolved:
memory: renesas-rpc-if: fix possible NULL pointer dereference of resource
The platform_get_resource_byname() can return NULL which would be
immediately dereferenced by resource_size(). Instead dereference it
after validating the resource.
Addresses-Coverity: Dereference null return value |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
It is possible to call lpfc_issue_els_plogi() passing a did for which no
matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a
null pointer to a lpfc_nodelist structure resulting in a null pointer
dereference.
Fix by returning an error status if no valid ndlp is found. Fix up comments
regarding ndlp reference counting. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Always enable the clk on resume
In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:
[ 1.586104] infra_m4u already disabled
[ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[ 1.598108] Modules linked in:
[ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[ 1.617487] Hardware name: Google Elm (DT)
[ 1.617491] Workqueue: pm pm_runtime_work
[ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)
[ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 1.659297] pc : clk_core_disable+0xb0/0xb8
[ 1.663475] lr : clk_core_disable+0xb0/0xb8
[ 1.667652] sp : ffff800011b9bbe0
[ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
[ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
[ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
[ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90
[ 1.692189] x21: 000000000000000a x20: ffff0000c0048500
[ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[ 1.702804] x17: 0000000000000000 x16: 0000000000000000
[ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000
[ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720
[ 1.718727] x11: 0720072007200720 x10: 0720072007200720
[ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
[ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
[ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
[ 1.750572] Call trace:
[ 1.753010] clk_core_disable+0xb0/0xb8
[ 1.756840] clk_core_disable_lock+0x24/0x40
[ 1.761105] clk_disable+0x20/0x30
[ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8
[ 1.769114] pm_generic_runtime_suspend+0x2c/0x48
[ 1.773815] __rpm_callback+0xe0/0x178
[ 1.777559] rpm_callback+0x24/0x88
[ 1.781041] rpm_suspend+0xdc/0x470
[ 1.784523] rpm_idle+0x12c/0x170
[ 1.787831] pm_runtime_work+0xa8/0xc0
[ 1.791573] process_one_work+0x1e8/0x360
[ 1.795580] worker_thread+0x44/0x478
[ 1.799237] kthread+0x150/0x158
[ 1.802460] ret_from_fork+0x10/0x30
[ 1.806034] ---[ end trace 82402920ef64573b ]---
[ 1.810728] ------------[ cut here ]------------
In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Make sure GHCB is mapped before updating
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB might not be mapped (depending on the previous VMEXIT),
which will result in a NULL pointer dereference.
The svm_complete_emulated_msr() routine will update the GHCB to inform
the caller of a RDMSR/WRMSR operation about any errors. While it is likely
that the GHCB will be mapped in this situation, add a safe guard
in this path to be certain a NULL pointer dereference is not encountered. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Fix NULL pointer dereference for ->get_features()
get_features ops of pci_epc_ops may return NULL, causing NULL pointer
dereference in pci_epf_test_alloc_space function. Let us add a check for
pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid
any such NULL pointer dereference and return -ENOTSUPP in case
pci_epc_feature is not found.
When the patch is not applied and EPC features is not implemented in the
platform driver, we see the following dump due to kernel NULL pointer
dereference.
Call trace:
pci_epf_test_bind+0xf4/0x388
pci_epf_bind+0x3c/0x80
pci_epc_epf_link+0xa8/0xcc
configfs_symlink+0x1a4/0x48c
vfs_symlink+0x104/0x184
do_symlinkat+0x80/0xd4
__arm64_sys_symlinkat+0x1c/0x24
el0_svc_common.constprop.3+0xb8/0x170
el0_svc_handler+0x70/0x88
el0_svc+0x8/0x640
Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400)
---[ end trace a438e3c5a24f9df0 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix potential null dereference on pointer status
There are calls to idxd_cmd_exec that pass a null status pointer however
a recent commit has added an assignment to *status that can end up
with a null pointer dereference. The function expects a null status
pointer sometimes as there is a later assignment to *status where
status is first null checked. Fix the issue by null checking status
before making the assignment.
Addresses-Coverity: ("Explicit null dereferenced") |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null pointer dereference in svc_rqst_free()
When alloc_pages_node() returns null in svc_rqst_alloc(), the
null rq_scratch_page pointer will be dereferenced when calling
put_page() in svc_rqst_free(). Fix it by adding a null check.
Addresses-Coverity: ("Dereference after null check") |
| In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe
When we converted this code to use dev_err_probe() we accidentally
removed a return. It means that if devm_clk_get() it will lead to an
Oops when we call clk_get_rate() on the next line. |
| In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix resume from sleep before interface was brought up
Since 8ce8c0abcba3 the driver queues work via priv->restart_work when
resuming after suspend, even when the interface was not previously
enabled. This causes a null dereference error as the workqueue is only
allocated and initialized in mcp251x_open().
To fix this we move the workqueue init to mcp251x_can_probe() as there
is no reason to do it later and repeat it whenever mcp251x_open() is
called.
[mkl: fix error handling in mcp251x_stop()] |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: Fix NULL deref when SEND is completed with error
When running some traffic and taking down the link on peer, a
retry counter exceeded error is received. This leads to
nvmet_rdma_error_comp which tried accessing the cq_context to
obtain the queue. The cq_context is no longer valid after the
fix to use shared CQ mechanism and should be obtained similar
to how it is obtained in other functions from the wc->qp.
[ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12).
[ 905.832048] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
[ 905.839919] PGD 0 P4D 0
[ 905.842464] Oops: 0000 1 SMP NOPTI
[ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE --------- - - 4.18.0-304.el8.x86_64 #1
[ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma]
[ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 <48> 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff
[ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246
[ 905.902387] RAX: 0000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000
[ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 0000000000000000
[ 905.916731] RBP: ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074
[ 905.923903] R10: 0000000000000000 R11: ffffab601c45fcc0 R12: 0000000000000010
[ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400
[ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72df940000(0000) knlGS:0000000000000000
[ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12).
[ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0
[ 905.961855] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 905.961857] PKRU: 55555554
[ 906.010315] Call Trace:
[ 906.012778] __ib_process_cq+0x89/0x170 [ib_core]
[ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core]
[ 906.022152] process_one_work+0x1a7/0x360
[ 906.026182] ? create_worker+0x1a0/0x1a0
[ 906.030123] worker_thread+0x30/0x390
[ 906.033802] ? create_worker+0x1a0/0x1a0
[ 906.037744] kthread+0x116/0x130
[ 906.040988] ? kthread_flush_work_fn+0x10/0x10
[ 906.045456] ret_from_fork+0x1f/0x40 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Reserve extra IRQ vectors
Commit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of
CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs.
That breaks vector allocation assumptions in qla83xx_iospace_config(),
qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions
computes maximum number of qpairs as:
ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default
response queue) - 1 (ATIO, in dual or pure target mode)
max_qpairs is set to zero in case of two CPUs and initiator mode. The
number is then used to allocate ha->queue_pair_map inside
qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is
left NULL but the driver thinks there are queue pairs available.
qla2xxx_queuecommand() tries to find a qpair in the map and crashes:
if (ha->mqenable) {
uint32_t tag;
uint16_t hwq;
struct qla_qpair *qpair = NULL;
tag = blk_mq_unique_tag(cmd->request);
hwq = blk_mq_unique_tag_to_hwq(tag);
qpair = ha->queue_pair_map[hwq]; # <- HERE
if (qpair)
return qla2xxx_mqueuecommand(host, cmd, qpair);
}
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc]
RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx]
Call Trace:
scsi_queue_rq+0x58c/0xa60
blk_mq_dispatch_rq_list+0x2b7/0x6f0
? __sbitmap_get_word+0x2a/0x80
__blk_mq_sched_dispatch_requests+0xb8/0x170
blk_mq_sched_dispatch_requests+0x2b/0x50
__blk_mq_run_hw_queue+0x49/0xb0
__blk_mq_delay_run_hw_queue+0xfb/0x150
blk_mq_sched_insert_request+0xbe/0x110
blk_execute_rq+0x45/0x70
__scsi_execute+0x10e/0x250
scsi_probe_and_add_lun+0x228/0xda0
__scsi_scan_target+0xf4/0x620
? __pm_runtime_resume+0x4f/0x70
scsi_scan_target+0x100/0x110
fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc]
process_one_work+0x1ea/0x3b0
worker_thread+0x28/0x3b0
? process_one_work+0x3b0/0x3b0
kthread+0x112/0x130
? kthread_park+0x80/0x80
ret_from_fork+0x22/0x30
The driver should allocate enough vectors to provide every CPU it's own HW
queue and still handle reserved (MB, RSP, ATIO) interrupts.
The change fixes the crash on dual core VM and prevents unbalanced QP
allocation where nr_hw_queues is two less than the number of CPUs. |
