* Re: 2.6.39-rc5+ BUG at scsi_run_queue+0x24/0xe3 [not found] ` <4DC03B0A.50209@sandia.gov> @ 2011-05-03 17:37 ` James Bottomley 2011-05-03 17:54 ` Jim Schutt 0 siblings, 1 reply; 4+ messages in thread From: James Bottomley @ 2011-05-03 17:37 UTC (permalink / raw) To: Jim Schutt; +Cc: linux-kernel, linux-scsi On Tue, 2011-05-03 at 11:27 -0600, Jim Schutt wrote: > James Bottomley wrote: > > On Tue, 2011-05-03 at 10:53 -0600, Jim Schutt wrote: > >> Please let me know if what further information you need, or if there is > >> anything I can do, to help resolve this. > > > > I think this is the fix (already in rc-fixes): > > > > James > > > > --- > > From 3e85ea868dbd60a84240be5c1eebc36841b9c568 Mon Sep 17 00:00:00 2001 > > From: James Bottomley <James.Bottomley@suse.de> > > Date: Sun, 1 May 2011 09:42:07 -0500 > > Subject: [PATCH] [SCSI] fix oops in scsi_run_queue() > > > > The recent commit closing the race window in device teardown: > > > > commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b > > Author: James Bottomley <James.Bottomley@suse.de> > > Date: Fri Apr 22 10:39:59 2011 -0500 > > > > [SCSI] put stricter guards on queue dead checks > > > > is causing a potential NULL deref in scsi_run_queue() because the > > q->queuedata may already be NULL by the time this function is called. > > Since we shouldn't be running a queue that is being torn down, simply > > add a NULL check in scsi_run_queue() to forestall this. > > > > Signed-off-by: James Bottomley <James.Bottomley@suse.de> > > > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > > index e9901b8..03979f4 100644 > > --- a/drivers/scsi/scsi_lib.c > > +++ b/drivers/scsi/scsi_lib.c > > @@ -404,6 +404,10 @@ static void scsi_run_queue(struct request_queue *q) > > LIST_HEAD(starved_list); > > unsigned long flags; > > > > + /* if the device is dead, sdev will be NULL, so no queue to run */ > > + if (!sdev) > > + return; > > + > > if (scsi_target(sdev)->single_lun) > > scsi_single_lun_run(sdev); > > > > Hmmm, with the above added, I still get BUGs. Here's an > example: > > [ 17.142931] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 17.143002] IP: [<ffffffffa01cf8c5>] scsi_run_queue+0x24/0xec [scsi_mod] Ooh, compiler optimisation, I think; try this instead James --- diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index e9901b8..0bac91e 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -400,10 +400,15 @@ static inline int scsi_host_is_busy(struct Scsi_Host *shost) static void scsi_run_queue(struct request_queue *q) { struct scsi_device *sdev = q->queuedata; - struct Scsi_Host *shost = sdev->host; + struct Scsi_Host *shost; LIST_HEAD(starved_list); unsigned long flags; + /* if the device is dead, sdev will be NULL, so no queue to run */ + if (!sdev) + return; + + shost = sdev->host; if (scsi_target(sdev)->single_lun) scsi_single_lun_run(sdev); ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: 2.6.39-rc5+ BUG at scsi_run_queue+0x24/0xe3 2011-05-03 17:37 ` 2.6.39-rc5+ BUG at scsi_run_queue+0x24/0xe3 James Bottomley @ 2011-05-03 17:54 ` Jim Schutt 2011-05-03 18:52 ` Jim Schutt 0 siblings, 1 reply; 4+ messages in thread From: Jim Schutt @ 2011-05-03 17:54 UTC (permalink / raw) To: James Bottomley; +Cc: linux-kernel, linux-scsi James Bottomley wrote: > On Tue, 2011-05-03 at 11:27 -0600, Jim Schutt wrote: >> James Bottomley wrote: >>> On Tue, 2011-05-03 at 10:53 -0600, Jim Schutt wrote: >>>> Please let me know if what further information you need, or if there is >>>> anything I can do, to help resolve this. >>> I think this is the fix (already in rc-fixes): >>> >>> James >>> >>> --- >>> From 3e85ea868dbd60a84240be5c1eebc36841b9c568 Mon Sep 17 00:00:00 2001 >>> From: James Bottomley <James.Bottomley@suse.de> >>> Date: Sun, 1 May 2011 09:42:07 -0500 >>> Subject: [PATCH] [SCSI] fix oops in scsi_run_queue() >>> >>> The recent commit closing the race window in device teardown: >>> >>> commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b >>> Author: James Bottomley <James.Bottomley@suse.de> >>> Date: Fri Apr 22 10:39:59 2011 -0500 >>> >>> [SCSI] put stricter guards on queue dead checks >>> >>> is causing a potential NULL deref in scsi_run_queue() because the >>> q->queuedata may already be NULL by the time this function is called. >>> Since we shouldn't be running a queue that is being torn down, simply >>> add a NULL check in scsi_run_queue() to forestall this. >>> >>> Signed-off-by: James Bottomley <James.Bottomley@suse.de> >>> >>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c >>> index e9901b8..03979f4 100644 >>> --- a/drivers/scsi/scsi_lib.c >>> +++ b/drivers/scsi/scsi_lib.c >>> @@ -404,6 +404,10 @@ static void scsi_run_queue(struct request_queue *q) >>> LIST_HEAD(starved_list); >>> unsigned long flags; >>> >>> + /* if the device is dead, sdev will be NULL, so no queue to run */ >>> + if (!sdev) >>> + return; >>> + >>> if (scsi_target(sdev)->single_lun) >>> scsi_single_lun_run(sdev); >>> >> Hmmm, with the above added, I still get BUGs. Here's an >> example: >> >> [ 17.142931] BUG: unable to handle kernel NULL pointer dereference at (null) >> [ 17.143002] IP: [<ffffffffa01cf8c5>] scsi_run_queue+0x24/0xec [scsi_mod] > > Ooh, compiler optimisation, I think; try this instead > > James > > --- > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index e9901b8..0bac91e 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -400,10 +400,15 @@ static inline int scsi_host_is_busy(struct Scsi_Host *shost) > static void scsi_run_queue(struct request_queue *q) > { > struct scsi_device *sdev = q->queuedata; > - struct Scsi_Host *shost = sdev->host; > + struct Scsi_Host *shost; > LIST_HEAD(starved_list); > unsigned long flags; > > + /* if the device is dead, sdev will be NULL, so no queue to run */ > + if (!sdev) > + return; > + > + shost = sdev->host; > if (scsi_target(sdev)->single_lun) > scsi_single_lun_run(sdev); > Yes, that definitely fixes things for me. Thanks!! -- Jim ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.39-rc5+ BUG at scsi_run_queue+0x24/0xe3 2011-05-03 17:54 ` Jim Schutt @ 2011-05-03 18:52 ` Jim Schutt 2011-05-03 20:36 ` James Bottomley 0 siblings, 1 reply; 4+ messages in thread From: Jim Schutt @ 2011-05-03 18:52 UTC (permalink / raw) To: James Bottomley; +Cc: linux-kernel, linux-scsi Hi James, FWIW, I noticed that commit 99f3c722e23 in scsi-rc-fixes-2.6 might want a Cc: stable@kernel.org, since the commit it's fixing, 86cbfb5607d4, had one. I'm not sure how that all works, but I thought I'd mention it just in case. -- Jim ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.39-rc5+ BUG at scsi_run_queue+0x24/0xe3 2011-05-03 18:52 ` Jim Schutt @ 2011-05-03 20:36 ` James Bottomley 0 siblings, 0 replies; 4+ messages in thread From: James Bottomley @ 2011-05-03 20:36 UTC (permalink / raw) To: Jim Schutt; +Cc: linux-kernel, linux-scsi On Tue, 2011-05-03 at 12:52 -0600, Jim Schutt wrote: > FWIW, I noticed that commit 99f3c722e23 in scsi-rc-fixes-2.6 > might want a Cc: stable@kernel.org, since the commit it's > fixing, 86cbfb5607d4, had one. > > I'm not sure how that all works, but I thought I'd mention it > just in case. Yes, good point; I'll add it ... destabilising the stable kernels wouldn't be a very good idea. James ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-05-03 20:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4DC0330F.6050906@sandia.gov>
[not found] ` <1304442019.10982.7.camel@mulgrave.site>
[not found] ` <4DC03B0A.50209@sandia.gov>
2011-05-03 17:37 ` 2.6.39-rc5+ BUG at scsi_run_queue+0x24/0xe3 James Bottomley
2011-05-03 17:54 ` Jim Schutt
2011-05-03 18:52 ` Jim Schutt
2011-05-03 20:36 ` James Bottomley
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).