Re: kern/56925: Amd64 server randomly panics

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

The following reply was made to PR kern/56925; it has been noted by GNATS.

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand%systella.fr@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, mlelstv%NetBSD.org@localhost
Subject: Re: kern/56925: Amd64 server randomly panics
Date: Thu, 14 Jul 2022 20:48:56 +0200

 Taylor R Campbell a écrit :
 > So it is in wake_ccb, as I guessed, and it looks like conn is null
 > when wake_ccb tries to acquire conn->c_lock:
 > 
 > https://nxr.netbsd.org/xref/src/sys/dev/iscsi/iscsi_utils.c?r=1.27#400
 > 
 > This can only happen if free_ccb had run before (or concurrently with)
 > ccb_timeout, nulling out ccb->ccb_connection before ccb_timeout read
 > it:
 > 
 > https://nxr.netbsd.org/xref/src/sys/dev/iscsi/iscsi_send.c?r=1.37#1661
 > 
 > Which free_ccb did it is not clear to me (lots of calls to it).  But
 > my guess is a race between successful command completion and the
 > callout firing.  If successful command completion tries callout_stop
 > to stop the timeout, but the callout had already begun firing on
 > another CPU, then successful command completion might call free_ccb
 > and null out ccb->ccb_connection just before ccb_timeout grabs it.
 > 
 > mlelstv: You recently(ish) worked on MP iscsi -- can you take a look?
 
 	For your information, this server acts as an initiator for two iscsi
 targets (/opt/ngspice and /opt/bacula). I haven't tested with only one
 target.
 
 	Best regards,
 
 	JB