so that __d_drop() can safely be done multiple times on
a dentry without corrupting other hash entries.

Noticed by Trond Myklebust.

list pointers to give us a nice oops if somebody is doing something
bad.

Also introduce hlist_del_rcu_init() - same as hlist_del_init().

into home.transmeta.com:/home/torvalds/v2.5/linux

into suse.cz:/home/perex/bk/linux-sound/work

  - fixed undefined symbols in PnP layer
  - fixed various warnings
  - azt3328 - fixed compilation in debug mode
  - ice17xx drivers - fixed compilation when both are built-in
  - vxpocket and vxp440
    - fixed compilation against the latest PCMCIA interface
    - fixed compilation when both drivers are built-in
  - removed empty sound/pci/ice1712/ak4524.c

into kroah.com:/home/greg/linux/BK/pci-2.5

This adds a new poisoning mode, distinguishing memory
that's uninitialized from memory that's freed.  The
slab code has been doing this for a while now.

[PATCH] PCI: add pci_find_next_bus() function to prevent people from walking pci bus lists themselves.

When foo is unlinked, nfs_unlink() does a sillyrename, this puts the
dentry on nfs_delete_queue, and (in the VFS) unhashes it from the
dcache.  This causes problems, since any later access to the
silly-renamed new .nfs file will create a NEW dentry that aliases the
one we originally created, but unhashed.

This causes various confusion, especially if we want to try to delete it
again later.

So fix this by not unhash the dentry after silly-renaming.  In 2.2, each
fs was responsible for doing a d_delete(), in 2.4 and later it happens
in the VFS layer and I think it was just an oversight that the 2.4 VFS
doesn't consider sillyrename (considering the code and comments that are
cruft).

Also fixed up some comments while debugging this.