public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linas Vepstas <linas@austin.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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: Fri, 19 Aug 2005 11:30:30 -0500	[thread overview]
Message-ID: <20050819163030.GA15648@austin.ibm.com> (raw)
In-Reply-To: <1124341108.8849.75.camel@gaston>

Hi,

On Thu, Aug 18, 2005 at 02:58:28PM +1000, Benjamin Herrenschmidt was heard to remark:
> On Thu, 2005-08-18 at 14:33 +1000, Paul Mackerras wrote:
> > This patch adds a
> > function to the PCI core that traverses all the PCI devices on a PCI
> > bus and under any PCI-PCI bridges on that bus (and so on), calling a
> > given function for each device.  

Paul, thanks, I'll use this in the next version, which I'm trying to
assemble now.

> Note that it's racy vs. removal of devices, 

...

> The whole idea that list*_safe routines pay you

OK, well, that makes me feel better, as I've stared at that code before, 
and wondered what magic made it work.

> I wonder if it's finally time to implement proper race free list
> iterators in the kernel. Not that difficult... A small struct iterator
> with a list head and the current elem pointer, and the "interated" list
> containing the list itself, a list of iterators and a lock. Iterators
> can then be "fixed" up on element removal with a fine grained lock on
> list structure access.

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

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?
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.

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.

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

  parent reply	other threads:[~2005-08-19 16:30 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 [this message]
2005-08-20  0:10     ` Benjamin Herrenschmidt

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=20050819163030.GA15648@austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=greg@kroah.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