dirty, and the same inode being reallocated and reused by create.
The unlock_new_inode and mark_inode_dirty manage to corrupt the
i_state flags and end up leaving I_LOCK|I_NEW set.

SGI Modid: 2.5.x-xfs:slinx:151120a

SGI Modid: 2.5.x-xfs:slinx:151423a

SGI Modid: 2.5.x-xfs:slinx:151428a

SGI Modid: 2.5.x-xfs:slinx:151226a

SGI Modid: 2.5.x-xfs:slinx:143601a

SGI Modid: 2.5.x-xfs:slinx:148936a

reclaimed and removed from memory by one thread while another thread
is attempting to reuse the inode and bring it back to life. There
was a window between the iget starting to reuse the inode and the
reclaim starting. Close the window by marking the inode as being
reused under the hash lock, and by abandoning the reclaim if this
is detected when it obtains the hash lock.

SGI Modid: 2.5.x-xfs:slinx:151123a

sleeps (which it might), this is not the right place for it to
be. There is also no reason for it to be under a spinlock.

SGI Modid: 2.5.x-xfs:slinx:151032a

they ended up the same somehow.

SGI Modid: 2.5.x-xfs:slinx:151227a

SGI Modid: 2.5.x-xfs:slinx:151422a

SGI Modid: 2.5.x-xfs:slinx:150782a

as some code paths can actually do this and handle the result.

SGI Modid: 2.5.x-xfs:slinx:150747a

out dummy log records to clear the log as these actually
have the effect of dirtying it in a readonly unmount.

SGI Modid: 2.5.x-xfs:slinx:150738a

right now size shows up as zero which is wrong.

SGI Modid: 2.5.x-xfs:slinx:150334a

mount update could have returned either sign, and statfs was 
just wrong.

SGI Modid: 2.5.x-xfs:slinx:150137a

SGI Modid: 2.5.x-xfs:slinx:150122a

SGI Modid: 2.5.x-xfs:slinx:150093a

SGI Modid: 2.5.x-xfs:slinx:149646a

SGI Modid: 2.5.x-xfs:slinx:149574a

than delayed write.

SGI Modid: 2.5.x-xfs:slinx:149418a

for log space, we give at least one thread a chance to flush
metadata and free more log space.

SGI Modid: 2.5.x-xfs:slinx:149321a6

SGI Modid: 2.5.x-xfs:slinx:148423a

build.

SGI Modid: 2.5.x-xfs:slinx:148158a

whenever ATTR_KERNOVAL flag is used. 

SGI Modid: 2.5.x-xfs:slinx:147567a

This adds a separate SERIAL_8250_ACPI config option and makes the
8250_acpi.c code dependent on ACPI_BUS (since acpi_bus_register_driver()
is a prerequisite).

into kernel.bkbits.net:/home/davem/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

I don't understand what was on the mind of Procom programmers,
why do all this inverted logic? Its plain confusing, revert it.
Thanks to DaveM for asking if the logic was inverted, I should
have killed this weird stuff a long time ago :-\

With this we make it easier to write correct network families as less
details need to be taken into account, as well in the current state we
make the non-refcounting protocols (the ones still keeping deliver_to_old_ones
in the tree) suck less. 8)

Left a WARN_ON in sk_del_node_init for a while, so that we can catch cases
where we're using __sock_put on a struct sock that has refcnt == 1, which
is not the case for all the ones I tested.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

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

SECURITY_INIT doesn't work when it is placed inside an output section.
Use our own version instead.

All current CPUs of ARMv5 or later can have ECC memory and can
support write allocations.

Noticed by Jun Sun.

Fix a couple of minor build errors caused by the recent system device
changes.