All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc: fix oops in pcibios_release_device() after pcibios_free_controller()
Date: Tue, 05 Jul 2016 12:55:31 +1000	[thread overview]
Message-ID: <1467687331.13965.27.camel@kernel.crashing.org> (raw)
In-Reply-To: <1467683085-3537-1-git-send-email-mauricfo@linux.vnet.ibm.com>

On Mon, 2016-07-04 at 22:44 -0300, Mauricio Faria de Oliveira wrote:
> It's possible to hit an oops/crash if pcibios_release_device() accesses the
> phb struct and it had been freed earlier -- by pcibios_free_controller() --
> as the memory it pointed to can be reused.
> 
> If after reuse 'phb->controller_ops.release_device' is non-NULL it will be
> called, but it points to an invalid location (that function pointer is not
> set anywhere in the code, so if it's non-NULL, that's not correct), and so
> it hits an oops and the system crashes.
> 
> The solution is to verify whether 'phb' is still in 'hose_list' before any
> access to it in pcibios_release_device() -- as it is removed from the list
> by pcibios_free_controller() -- and ensure it cannot be used after kfree().
> 
> That problem can happen with the pSeries platform's DLPAR remove operation
> if references to devices are held until after the pcibios_free_controller()
> function runs, and then released - exercising pcibios_release_device() path.

Have you considered instead adding a kref to the PHB and only freeing
it when all devices have been freed ? Or it's too hard to tract device
creation ?

Ben.

  reply	other threads:[~2016-07-05  2:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05  1:44 [PATCH] powerpc: fix oops in pcibios_release_device() after pcibios_free_controller() Mauricio Faria de Oliveira
2016-07-05  2:55 ` Benjamin Herrenschmidt [this message]
2016-07-05 13:34   ` Mauricio Faria de Oliveira
2016-07-12 23:07   ` Mauricio Faria de Oliveira
2016-07-13 13:52     ` Mauricio Faria de Oliveira

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=1467687331.13965.27.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mauricfo@linux.vnet.ibm.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.