Re: [PATCH] Add pci_walk_bus function to PCI core (nonrecursive)

[Benjamin Herrenschmidt]

> Wow. A list of iterators to be fixed up ... I get the idea, but it does
> add a fair amount of complexity.  

Not that much, been there done that, it's actually quite simple :)

> Would it be easier (and simpler to maintain/debug) to "get" all items
> on the list first, before iterating on them, and only then iterate?

How do you protect against change of your "next" pointer ? by taking a
global lock, peeking at it, getting it, unlocking ? That would work in
that case I suppose ...

> This should work, as long as removing an item doesn't trash its "next" 
> pointer.  The "next" pointer gets whacked only when the use-count goes 
> to zero.

A fine grained lock used when adding/removing items and when "peeking"
at next might work there..

> The idea is that while traversing the list, its OK if the "next" pointer
> is pointing to a node that has removed from the list; in fact, its OK to
> traverse to that node; eventually, traversing will eventually lead back
> to a valid head.

It's just making the race less likely to happen, but it's still there.
Once the object you are peeking (or your next object, whatever) is
unhooked from the list, that means that the next point it contains is
crap. At any  time while you are playing with it, somebody may free the
"next" object, and since you are unhooked form the list, your own "next"
pointer will not be updated -> kaboom.

> I know that the above sounds crazy, but I think it could work, and be 
> a relatively low-tech but capable solution.  It does presume that elems
> have generic get/put routines.
> 
> --linas

-
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/