All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Felipe Balbi <balbi@ti.com>, Rob Herring <robh+dt@kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 1/3] of/device: manage resources similar to\r platform_device_add
Date: Fri, 20 Mar 2015 11:29:54 +0000	[thread overview]
Message-ID: <20150320112954.A3903C419C2@trevor.secretlab.ca> (raw)
In-Reply-To: <54C17087.7060003@ti.com>

On Thu, 22 Jan 2015 15:49:59 -0600
, Suman Anna <s-anna@ti.com>
 wrote:
> Hi Grant,
> 
> On 01/13/2015 05:04 PM, Suman Anna wrote:
> > On 01/13/2015 04:00 PM, Rob Herring wrote:
> >> On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna <s-anna@ti.com> wrote:
> >>> Hi Rob,
> >>>
> >>> On 01/13/2015 02:38 PM, Rob Herring wrote:
> >>>> On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna <s-anna@ti.com> wrote:
> >>>>> Drivers can use of_platform_populate() to create platform devices
> >>>>> for children of the device main node, and a complementary API
> >>>>> of_platform_depopulate() is provided to delete these child platform
> >>>>> devices. The of_platform_depopulate() leverages the platform API
> >>>>> for performing the cleanup of these devices.
> >>>>>
> >>>>> The platform device resources are managed differently between
> >>>>> of_device_add and platform_device_add, and this asymmetry causes
> >>>>> a kernel oops in platform_device_del during removal of the resources.
> >>>>> Manage the platform device resources similar to platform_device_add
> >>>>> to fix this kernel oops.
> >>>>
> >>>> This is a known issue and has been attempted to be fixed before (I
> >>>> believe there is a revert in mainline). The problem is there are known
> >>>> devicetrees which have overlapping resources and they will break with
> >>>> your change.
> >>>
> >>> Are you referring to 02bbde7849e6 (Revert "of: use
> >>> platform_device_add")?
> >>
> >> I believe that's the one.
> >>
> >>> That one seems to be in registration path, and
> >>> this crash is in the unregistration path. If so, to fix the crash,
> >>> should we be skipping the release_resource() for now in
> >>> platform_device_del for DT nodes, or replace platform_device_unregister
> >>> with of_device_unregister in of_platform_device_destroy()?
> >>
> >> IIRC, the problem is inserting a resource twice on add from 2
> >> different nodes, not the removal path. Perhaps we could make a
> >> collision non-fatal for in the DT case.
> > 
> > We may be talking two different things here, I understand that this
> > patch would create an issue with inserting a resource twice in the
> > devicetrees with overlapping resources (just like the commit that was
> > reverted above), but the crash is on devices with resources whose
> > parent, child, sibling pointers have never been initialized (the
> > of_device_add path does not touch these at all), and get dereferenced in
> > platform_device_del()->release_resource(). See the following that has a
> > better explanation [1].
> > 
> > regards
> > Suman
> > 
> > [1]
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274412.html
> > 
> > 
> >> Grant may have some ideas on
> >> what's needed here.
> 
> Ping, any suggestions here? Do we ought to replace
> platform_device_unregister() with of_device_unregister() similar to the
> approach taken in 02bbde7849e6 (Revert "of: use platform_device_add")?

Hi Suman,

Yes, I think the solution to both problems is to create an
of_device_unregister() function. It's not the prettiest thing, but I
think it is for the best.

g.


WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@linaro.org (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/3] of/device: manage resources similar to\r platform_device_add
Date: Fri, 20 Mar 2015 11:29:54 +0000	[thread overview]
Message-ID: <20150320112954.A3903C419C2@trevor.secretlab.ca> (raw)
In-Reply-To: <54C17087.7060003@ti.com>

On Thu, 22 Jan 2015 15:49:59 -0600
, Suman Anna <s-anna@ti.com>
 wrote:
> Hi Grant,
> 
> On 01/13/2015 05:04 PM, Suman Anna wrote:
> > On 01/13/2015 04:00 PM, Rob Herring wrote:
> >> On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna <s-anna@ti.com> wrote:
> >>> Hi Rob,
> >>>
> >>> On 01/13/2015 02:38 PM, Rob Herring wrote:
> >>>> On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna <s-anna@ti.com> wrote:
> >>>>> Drivers can use of_platform_populate() to create platform devices
> >>>>> for children of the device main node, and a complementary API
> >>>>> of_platform_depopulate() is provided to delete these child platform
> >>>>> devices. The of_platform_depopulate() leverages the platform API
> >>>>> for performing the cleanup of these devices.
> >>>>>
> >>>>> The platform device resources are managed differently between
> >>>>> of_device_add and platform_device_add, and this asymmetry causes
> >>>>> a kernel oops in platform_device_del during removal of the resources.
> >>>>> Manage the platform device resources similar to platform_device_add
> >>>>> to fix this kernel oops.
> >>>>
> >>>> This is a known issue and has been attempted to be fixed before (I
> >>>> believe there is a revert in mainline). The problem is there are known
> >>>> devicetrees which have overlapping resources and they will break with
> >>>> your change.
> >>>
> >>> Are you referring to 02bbde7849e6 (Revert "of: use
> >>> platform_device_add")?
> >>
> >> I believe that's the one.
> >>
> >>> That one seems to be in registration path, and
> >>> this crash is in the unregistration path. If so, to fix the crash,
> >>> should we be skipping the release_resource() for now in
> >>> platform_device_del for DT nodes, or replace platform_device_unregister
> >>> with of_device_unregister in of_platform_device_destroy()?
> >>
> >> IIRC, the problem is inserting a resource twice on add from 2
> >> different nodes, not the removal path. Perhaps we could make a
> >> collision non-fatal for in the DT case.
> > 
> > We may be talking two different things here, I understand that this
> > patch would create an issue with inserting a resource twice in the
> > devicetrees with overlapping resources (just like the commit that was
> > reverted above), but the crash is on devices with resources whose
> > parent, child, sibling pointers have never been initialized (the
> > of_device_add path does not touch these at all), and get dereferenced in
> > platform_device_del()->release_resource(). See the following that has a
> > better explanation [1].
> > 
> > regards
> > Suman
> > 
> > [1]
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274412.html
> > 
> > 
> >> Grant may have some ideas on
> >> what's needed here.
> 
> Ping, any suggestions here? Do we ought to replace
> platform_device_unregister() with of_device_unregister() similar to the
> approach taken in 02bbde7849e6 (Revert "of: use platform_device_add")?

Hi Suman,

Yes, I think the solution to both problems is to create an
of_device_unregister() function. It's not the prettiest thing, but I
think it is for the best.

g.

  reply	other threads:[~2015-03-20 11:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 17:30 [RFC PATCH 0/3] of_platform_depopulate crash fixes Suman Anna
2015-01-07 17:30 ` Suman Anna
2015-01-07 17:30 ` Suman Anna
2015-01-07 17:30 ` [RFC PATCH 1/3] of/device: manage resources similar to platform_device_add Suman Anna
2015-01-07 17:30   ` Suman Anna
2015-01-07 17:30   ` Suman Anna
2015-01-13 20:38   ` Rob Herring
2015-01-13 20:38     ` Rob Herring
2015-01-13 20:38     ` Rob Herring
2015-01-13 21:25     ` Suman Anna
2015-01-13 21:25       ` Suman Anna
2015-01-13 21:25       ` Suman Anna
2015-01-13 22:00       ` Rob Herring
2015-01-13 22:00         ` Rob Herring
2015-01-13 22:00         ` Rob Herring
2015-01-13 23:04         ` Suman Anna
2015-01-13 23:04           ` Suman Anna
2015-01-13 23:04           ` Suman Anna
2015-01-22 21:49           ` Suman Anna
2015-01-22 21:49             ` Suman Anna
2015-01-22 21:49             ` Suman Anna
2015-03-20 11:29             ` Grant Likely [this message]
2015-03-20 11:29               ` Grant Likely
2015-03-20 11:29               ` Grant Likely
2015-01-07 17:30 ` [RFC PATCH 2/3] core: platform: fix an invalid kfree during of_platform_depopulate Suman Anna
2015-01-07 17:30   ` Suman Anna
2015-01-07 17:30   ` Suman Anna
2015-01-13 22:27   ` Rob Herring
2015-01-13 22:27     ` Rob Herring
2015-01-13 22:27     ` Rob Herring
2015-01-13 22:53     ` Suman Anna
2015-01-13 22:53       ` Suman Anna
2015-01-13 22:53       ` Suman Anna
2015-01-07 17:30 ` [RFC PATCH 3/3] of/unittest: fix trailing semi-colons on conditional selftest Suman Anna
2015-01-07 17:30   ` Suman Anna
2015-01-07 17:30   ` Suman Anna

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=20150320112954.A3903C419C2@trevor.secretlab.ca \
    --to=grant.likely@linaro.org \
    --cc=balbi@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=s-anna@ti.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.