On Wed, 2019-07-10 at 17:47 +0000, Lee Duncan wrote:
> On 7/10/19 12:30 AM, Yang Bin wrote:
>
> > From: " Yang Bin "<yang.bin18@xxxxxxxxxx>
> >
> > Before xmit,iscsi may disconnect just now.
> > So must check connection sock NULL or not,or kernel will crash for
> > accessing NULL pointer.
> >
> > Signed-off-by: Yang Bin <yang.bin18@xxxxxxxxxx>
> > ---
> > drivers/scsi/iscsi_tcp.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> > index 7bedbe8..a59c49f 100644
> > --- a/drivers/scsi/iscsi_tcp.c
> > +++ b/drivers/scsi/iscsi_tcp.c
> > @@ -264,6 +264,9 @@ static int iscsi_sw_tcp_xmit_segment(struct
> > iscsi_tcp_conn *tcp_conn,
> > unsigned int copied = 0;
> > int r = 0;
> >
> > + if (!sk)
> > + return -ENOTCONN;
> > +
> > while (!iscsi_tcp_segment_done(tcp_conn, segment, 0, r)) {
> > struct scatterlist *sg;
> > unsigned int offset, copy;
> >
>
> If the socket can be closed right before iscsi_sw_tcp_xmit_segment()
> is called, can it be called in the middle of sending segments? (In
> which case the check would have to be in the while loop.)
I think the important point is: is this an actual observed bug or just
a theoretical problem?
The reason for asking is this call is controlled directly by the
ISCSI_UEVENT_DESTROY_CONN event sent by the iscsi daemon. Obviously if
the daemon goes haywire and doesn't shut down the connection before
sending the destroy event, we may get the crash, but I would be
inclined to say fix the daemon.
James
