All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: Lee Duncan <LDuncan@suse.com>, Yang Bin <yang.bin18@zte.com.cn>
Cc: "open-iscsi@googlegroups.com" <open-iscsi@googlegroups.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"cleech@redhat.com" <cleech@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"wang.liang82@zte.com.cn" <wang.liang82@zte.com.cn>,
	"wang.yi59@zte.com.cn" <wang.yi59@zte.com.cn>,
	"xue.zhihong@zte.com.cn" <xue.zhihong@zte.com.cn>
Subject: Re: [PATCH] Check sk before sendpage
Date: Wed, 10 Jul 2019 11:52:11 -0700	[thread overview]
Message-ID: <1562784731.3213.98.camel@linux.ibm.com> (raw)
In-Reply-To: <1bc364ff-5bff-47ac-611a-f75c43f4bd1b@suse.com>

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@zte.com.cn>
> > 
> > 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@zte.com.cn>
> > ---
> >  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

  reply	other threads:[~2019-07-10 18:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  7:30 [PATCH] Check sk before sendpage Yang Bin
     [not found] ` <1562743809-31133-1-git-send-email-yang.bin18-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.org>
2019-07-10 17:47   ` Lee Duncan
2019-07-10 17:47     ` Lee Duncan
2019-07-10 18:52     ` James Bottomley [this message]
     [not found]       ` <1562784731.3213.98.camel-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2019-07-11  7:42         ` yang.bin18-Th6q7B73Y6EnDS1+zs4M5A

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1562784731.3213.98.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=LDuncan@suse.com \
    --cc=cleech@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=open-iscsi@googlegroups.com \
    --cc=wang.liang82@zte.com.cn \
    --cc=wang.yi59@zte.com.cn \
    --cc=xue.zhihong@zte.com.cn \
    --cc=yang.bin18@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.