netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net v2] ibmvnic: continue fatal error reset after passive init
@ 2020-12-23 20:49 Lijun Pan
  2020-12-23 21:00 ` patchwork-bot+netdevbpf
  0 siblings, 1 reply; 2+ messages in thread
From: Lijun Pan @ 2020-12-23 20:49 UTC (permalink / raw)
  To: netdev; +Cc: Lijun Pan

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>
---
v2: reword the commit message to explain it better.

 drivers/net/ethernet/ibm/ibmvnic.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index b370c88a43f1..237a36040689 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2342,8 +2342,7 @@ static void __ibmvnic_reset(struct work_struct *work)
 				set_current_state(TASK_UNINTERRUPTIBLE);
 				schedule_timeout(60 * HZ);
 			}
-		} else if (!(rwi->reset_reason == VNIC_RESET_FATAL &&
-				adapter->from_passive_init)) {
+		} else {
 			rc = do_reset(adapter, rwi, reset_state);
 		}
 		kfree(rwi);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH net v2] ibmvnic: continue fatal error reset after passive init
  2020-12-23 20:49 [PATCH net v2] ibmvnic: continue fatal error reset after passive init Lijun Pan
@ 2020-12-23 21:00 ` patchwork-bot+netdevbpf
  0 siblings, 0 replies; 2+ messages in thread
From: patchwork-bot+netdevbpf @ 2020-12-23 21:00 UTC (permalink / raw)
  To: Lijun Pan; +Cc: netdev

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Wed, 23 Dec 2020 14:49:04 -0600 you wrote:
> 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."
> 
> [...]

Here is the summary with links:
  - [net,v2] ibmvnic: continue fatal error reset after passive init
    https://git.kernel.org/netdev/net/c/1f45dc220667

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-12-23 21:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-23 20:49 [PATCH net v2] ibmvnic: continue fatal error reset after passive init Lijun Pan
2020-12-23 21:00 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).