summaryrefslogtreecommitdiffstats
path: root/net/netrom
diff options
context:
space:
mode:
authorLijun Pan <ljp@linux.ibm.com>2020-12-23 14:49:04 -0600
committerJakub Kicinski <kuba@kernel.org>2020-12-23 12:56:10 -0800
commit1f45dc22066797479072978feeada0852502e180 (patch)
tree0fd2970c6db1fb8816050dee1542e51bec3d583e /net/netrom
parent5d41f9b7ee7a5a5138894f58846a4ffed601498a (diff)
downloadlinux-1f45dc22066797479072978feeada0852502e180.tar.bz2
ibmvnic: continue fatal error reset after passive init
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." 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 0e435befaea4 ("ibmvnic: fix NULL pointer dereference in ibmvic_reset_crq") and commit a0faaa27c716 ("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: f9c6cea0b385 ("ibmvnic: Skip fatal error reset after passive init") Signed-off-by: Lijun Pan <ljp@linux.ibm.com> Link: https://lore.kernel.org/r/20201223204904.12677-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net/netrom')
0 files changed, 0 insertions, 0 deletions