All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Luo Jiaxing <luojiaxing@huawei.com>
Cc: saravanak@google.com, jejb@linux.ibm.com,
	James.Bottomley@suse.de, James.Bottomley@hansenpartnership.com,
	john.garry@huawei.com, linux-kernel@vger.kernel.org,
	linuxarm@huawei.com
Subject: Re: [PATCH v1] driver core: Use list_del_init to replace list_del at device_links_purge()
Date: Wed, 8 Jan 2020 13:26:58 +0100	[thread overview]
Message-ID: <20200108122658.GA2365903@kroah.com> (raw)
In-Reply-To: <1578483244-50723-1-git-send-email-luojiaxing@huawei.com>

On Wed, Jan 08, 2020 at 07:34:04PM +0800, Luo Jiaxing wrote:
> We found that enabling kernel compilation options CONFIG_SCSI_ENCLOSURE and
> CONFIG_ENCLOSURE_SERVICES, repeated initialization and deletion of the same
> SCSI device will cause system panic, as follows:
> [72.425705] Unable to handle kernel paging request at virtual address
> dead000000000108
> ...
> [72.595093] Call trace:
> [72.597532] device_del + 0x194 / 0x3a0
> [72.601012] enclosure_remove_device + 0xbc / 0xf8
> [72.605445] ses_intf_remove + 0x9c / 0xd8
> [72.609185] device_del + 0xf8 / 0x3a0
> [72.612576] device_unregister + 0x14 / 0x30
> [72.616489] __scsi_remove_device + 0xf4 / 0x140
> [72.620747] scsi_remove_device + 0x28 / 0x40
> [72.624745] scsi_remove_target + 0x1c8 / 0x220
> 
> After analysis, we see that in the error scenario, the ses module has the
> following calling sequence:
> device_register() -> device_del() -> device_add() -> device_del().
> The first call to device_del() is fine, but the second call to device_del()
> will cause a system panic.

Is this all on the same device structure?  If so, that's not ok, you
can't do that, once device_del() is called on the memory location, you
can not call device_add() on it again.

How are you triggering this from userspace?

thanks,

greg k-h

  parent reply	other threads:[~2020-01-08 12:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 11:34 [PATCH v1] driver core: Use list_del_init to replace list_del at device_links_purge() Luo Jiaxing
2020-01-08 11:53 ` John Garry
2020-01-08 12:26 ` Greg KH [this message]
2020-01-08 14:50   ` John Garry
2020-01-08 15:44     ` Greg KH
2020-01-08 15:51     ` James Bottomley
2020-01-08 15:57       ` Greg KH
2020-01-08 16:01         ` James Bottomley
2020-01-08 16:08           ` John Garry
2020-01-08 17:10             ` John Garry
2020-01-09  1:04               ` James Bottomley
2020-01-14 15:07                 ` Greg KH
2020-01-14 15:20                   ` John Garry
2020-01-14 15:28                     ` Greg KH

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=20200108122658.GA2365903@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=James.Bottomley@suse.de \
    --cc=jejb@linux.ibm.com \
    --cc=john.garry@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=luojiaxing@huawei.com \
    --cc=saravanak@google.com \
    /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.