[PATCH 5/7] powerpc: prom.c support for updating and removing

[Nathan Lynch]

Dave C Boutcher wrote:
> Add support for updating and removing device tree 
> properties.  Since we hand out pointers to properties with gay
> abandon, we can't just free the property storage.  Instead we 
> move deleted, or the old copy of an updated property, to a 
> "dead properties" list.
> 
> Also note, its not feasable to kref device tree properties. 
> we call get_property() all over the kernel in a wild variety
> of contexts.

It's really not all that bad -- just arch/{powerpc,ppc} and the
occasional pmac driver.  I believe use of get_property in interrupt
context is rare (maybe eeh does it).

> One consequence of this change is that we now take a 
> read_lock(&devtree_lock) when doing get_property().

What does this really buy us?  Notwithstanding the abuse in
prom_add_property, devtree_lock currently protects:

o  traversals of the device tree through device_node's allnext,
   parent, child, and sibling pointers (read side)

o  device node insertion and removal (write side)

Until now, the assumption has been that properties are immutable at
runtime.

AFAICT, the patch series doesn't fix the real issue -- how do you
prevent code from using properties that have been removed or changed?
Just preventing oopses in the property list traversal code doesn't
address that.  I think we need to at least audit for code that caches
the pointer returned by get_property, and consider adding to the
existing notification mechanism in the reconfig code for that purpose.

Maybe you could tell us more specifics -- e.g. is there a known set of
properties that are subject to update or removal?  At what point(s) in
the system's operation are property addition/removal/updates supposed
to occur (like, during resume?).