From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>, Greg KH <greg@kroah.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add pci_walk_bus function to PCI core (nonrecursive)
Date: Sat, 20 Aug 2005 10:10:30 +1000 [thread overview]
Message-ID: <1124496631.5197.96.camel@gaston> (raw)
In-Reply-To: <20050819163030.GA15648@austin.ibm.com>
> 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
prev parent reply other threads:[~2005-08-20 0:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 4:33 [PATCH] Add pci_walk_bus function to PCI core (nonrecursive) Paul Mackerras
2005-08-18 4:58 ` Benjamin Herrenschmidt
2005-08-18 5:13 ` Greg KH
2005-08-18 8:02 ` Benjamin Herrenschmidt
2005-08-19 16:30 ` Linas Vepstas
2005-08-20 0:10 ` Benjamin Herrenschmidt [this message]
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=1124496631.5197.96.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=linas@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=paulus@samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox