Skip to content

Commit 1f45dc2

Browse files
Lijun Pankuba-moo
authored andcommitted
ibmvnic: continue fatal error reset after passive init
Commit f9c6cea ("ibmvnic: Skip fatal error reset after passive init") says "If the passive CRQ initialization occurs before the FATAL reset task is processed, the FATAL error reset task would try to access a CRQ message queue that was freed, causing an oops. The problem may be most likely to occur during DLPAR add vNIC with a non-default MTU, because the DLPAR process will automatically issue a change MTU request. Fix this by not processing fatal error reset if CRQ is passively initialized after client-driven CRQ initialization fails." The original commit skips a specific reset condition, but that does not fix the problem it claims to fix, and misses a reset condition. The effective fix is commit 0e435be ("ibmvnic: fix NULL pointer dereference in ibmvic_reset_crq") and commit a0faaa2 ("ibmvnic: fix NULL pointer dereference in reset_sub_crq_queues"). With above two fixes, there are no more crashes seen as described even without the original commit, so I would like to revert the original commit. Fixes: f9c6cea ("ibmvnic: Skip fatal error reset after passive init") Signed-off-by: Lijun Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
1 parent 5d41f9b commit 1f45dc2

File tree

1 file changed

+1
-2
lines changed

1 file changed

+1
-2
lines changed

drivers/net/ethernet/ibm/ibmvnic.c

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2342,8 +2342,7 @@ static void __ibmvnic_reset(struct work_struct *work)
23422342
set_current_state(TASK_UNINTERRUPTIBLE);
23432343
schedule_timeout(60 * HZ);
23442344
}
2345-
} else if (!(rwi->reset_reason == VNIC_RESET_FATAL &&
2346-
adapter->from_passive_init)) {
2345+
} else {
23472346
rc = do_reset(adapter, rwi, reset_state);
23482347
}
23492348
kfree(rwi);

0 commit comments

Comments
 (0)