All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sitsofe Wheeler <sitsofe@yahoo.com>
To: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] unable to handle kernel paging request in next-20080516
Date: Fri, 23 May 2008 20:34:25 +0100	[thread overview]
Message-ID: <g176e5$6fb$1@ger.gmane.org> (raw)
In-Reply-To: 1211456081.3956.39.camel@localhost.localdomain

<posted & mailed>

James Bottomley wrote:

> Actually, I think this is a very subtle bug; what I think is happening
> is that after Hannes sysfs changes, we now add scsi_bus_type to the
> target device.  However, scsi_bus_uevent() unconditionally casts from
> dev to a struct scsi_device and then looks at the type entry.  My theory
> is that in this particular config going from struct scsi_target to
> struct device and back to struct scsi_device actually tips us over into
> unmapped space for the -> type deref.
> 
> Hopefully this should fix it by checking the device type before doing
> the deref.

This fixed the problem for me (it was horribly intermittant but I've done
10+ consecutive reboots without seeing an oopos). I changed the patch to
printk everytime the condition was hit and it seems to happen twice per
PATA device - once after each scsi?: pata_via message and then again after
each scsi 0:0:0:0: Direct-Accesss ATA DISKID etc : 0 ANSI: 5 .

The thing I don't understand about your explanation is that it sounds like
the device struct is being round-tripped (but is just being cast to
different things along the way). If this is the case why would this problem
ever arise? Surely if it is really a struct scsi_device underneath there
should be no problem?

-- 
Sitsofe | http://sucs.org/~sits/


WARNING: multiple messages have this Message-ID (diff)
From: Sitsofe Wheeler <sitsofe@yahoo.com>
To: linux-kernel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Subject: Re: [BUG] unable to handle kernel paging request in next-20080516
Date: Fri, 23 May 2008 20:34:25 +0100	[thread overview]
Message-ID: <g176e5$6fb$1@ger.gmane.org> (raw)
In-Reply-To: 1211456081.3956.39.camel@localhost.localdomain

<posted & mailed>

James Bottomley wrote:

> Actually, I think this is a very subtle bug; what I think is happening
> is that after Hannes sysfs changes, we now add scsi_bus_type to the
> target device.  However, scsi_bus_uevent() unconditionally casts from
> dev to a struct scsi_device and then looks at the type entry.  My theory
> is that in this particular config going from struct scsi_target to
> struct device and back to struct scsi_device actually tips us over into
> unmapped space for the -> type deref.
> 
> Hopefully this should fix it by checking the device type before doing
> the deref.

This fixed the problem for me (it was horribly intermittant but I've done
10+ consecutive reboots without seeing an oopos). I changed the patch to
printk everytime the condition was hit and it seems to happen twice per
PATA device - once after each scsi?: pata_via message and then again after
each scsi 0:0:0:0: Direct-Accesss ATA DISKID etc : 0 ANSI: 5 .

The thing I don't understand about your explanation is that it sounds like
the device struct is being round-tripped (but is just being cast to
different things along the way). If this is the case why would this problem
ever arise? Surely if it is really a struct scsi_device underneath there
should be no problem?

-- 
Sitsofe | http://sucs.org/~sits/


  reply	other threads:[~2008-05-23 19:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-17 12:50 [BUG] unable to handle kernel paging request in next-20080516 Sitsofe Wheeler
2008-05-18  9:14 ` Andrew Morton
2008-05-18 11:22   ` [BUG] unable to handle kernel paging request in next-20080516 (scsi_bus_uevent) Sitsofe Wheeler
2008-05-18 16:00   ` [BUG] unable to handle kernel paging request in next-20080516 Sitsofe Wheeler
2008-05-18 17:47   ` Greg KH
2008-05-18 20:22     ` Sitsofe Wheeler
2008-05-22 11:34   ` James Bottomley
2008-05-23 19:34     ` Sitsofe Wheeler [this message]
2008-05-23 19:34       ` Sitsofe Wheeler
2008-05-23 20:26       ` James Bottomley

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='g176e5$6fb$1@ger.gmane.org' \
    --to=sitsofe@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /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.