ibmvnic: continue fatal error reset after passive init
authorLijun Pan <ljp@linux.ibm.com>
Sat, 19 Dec 2020 21:40:34 +0000 (15:40 -0600)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 12 Jan 2021 19:16:12 +0000 (20:16 +0100)
commit6d003fe7fe87578c64a8845db90ae7f4309e8eb9
tree6676be7b69268717dc4431a7e23f876d23ea7a65
parent3d16088a9668fa070eba83714b9b162ea0bd4179
ibmvnic: continue fatal error reset after passive init

[ Upstream commit 1f45dc22066797479072978feeada0852502e180 ]

Commit f9c6cea0b385 ("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."

Even with this commit, we still see similar kernel crashes. In order
to completely solve this problem, we'd better continue the fatal error
reset, capture the kernel crash, and try to fix it from that end.

Fixes: f9c6cea0b385 ("ibmvnic: Skip fatal error reset after passive init")
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Link: https://lore.kernel.org/r/20201219214034.21123-1-ljp@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/net/ethernet/ibm/ibmvnic.c