Re: [RFC] How should delete_resource() handle children?

[Randy.Dunlap]

On Tue, 10 Feb 2004 19:33:49 +0000 Matthew Wilcox <willy@xxxxxxxxxx> wrote:

| 
| If you call release_resource() on a resource that has children, all
| of those children are silently removed from the list too.  Does anybody
| currently depend on that behaviour?
| 
| There are three valid behaviours I can think of for this:
| 
|  * Current behaviour, on the assumption that all the children of this
|    resource are also owned by this device, and so removing them is the
|    right thing to do.
| 
|  * BUG_ON() on the basis you should never do this.
| 
|  * Reparent the children to the parent resource of the one being released.
| 
| The first option has the problem that if the children of the resource
| belong to some other part of the system, they still have pointers into
| their parent which is now gone.  Memory corruption will follow.
| 
| The second option has the problem that if you *do* need to delete this
| resource but keep its children linked in, you can't do it in a race-free
| manner.
| 
| The third option has the problem that if you were relying on the current
| behaviour of release_resource(), the parent/siblings of the deleted
| resource still have references to objects you thought were deleted.
| 
| 
| I like the third option best.  Now that we have insert_resource(), the
| corresponding release_resource() should leave the children in the state
| they were in before.
| 
| An alternative possibility would be to introduce a remove_resource()
| that implements the reparenting option and leave the current behaviour
| of release_resource() alone.
| 
| 
| Comments?

Ideally (or if nothing depends on the current behavior), I think it
should just be an error (return -EINVAL), not a BUG_ON().  I.e.,
releasing a resource should be an explicit action.

Do we know of cases where parents are removed but children need to
remain?  Examples?

--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/