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

the extents code on 64-bit machines

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

related to read/write locking the behavior change.

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

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

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

the inode.  The inode could have changed since before the lock.

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

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

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

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

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

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

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

when there is a real problem.

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

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

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

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

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

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

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

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

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

and in the out of mem case, panic in the sleep case, not the 
non-sleep case.

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

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

confuse user space. This limits the maximum amount of names in
a directory on linux to 2Gbytes, which should not be a problem.

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

fields after a create/remove etc. Make sure we pass in all the
flags for the status fields we want. NBLOCKS was missing and
working by accident.

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

the filldir fixup at the linvfs layer. This is the V2 directory
component, the V1 code still needs fixing up. We now return the
same directory offsets as Irix does.

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

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

do not add one.

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

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

This is a fix made almost a month ago, during the flurry of signal changes.
I didn't realize until today that this hadn't made it into 2.5.  Sorry
about the delay.

This fix is necessary to avoid sometimes wedging in uninterruptible sleep
when doing a multithreaded core dump triggered by a process signal (kill)
rather than a trap.  You can reproduce the problem by running your favorite
multithreaded program (NPTL) and then using "kill -SEGV" on it.  It will
often wedge.  The actual fix could be just a two line diff:

+                       if (current->signal->group_exit)
+                               goto dequeue;

after the group_exit_task check.  That is the fix that has been used in
Ingo's backport for weeks and tested heavily (well, as heavily as core
dumping ever gets tested, but it's been in our production systems).

But I broke the hair out into a separate function.  The patch below has the
same effect as the two-liner, and no other difference.  I have tested
2.5.64 with this patch and it works for me, though I haven't beat on it.

The way the wedge happens is that for a core-dump signal group_send_sig_info
does a group stop of other threads before the one thread handles the fatal
signal.  If the fatal thread gets into do_coredump and coredump_wait first,
then other threads see the group stop and suspend with SIGKILL pending.
All other fatal cases clear group_stop_count, so this is the only way this
ever happens.  Checking group_exit fixes it.  I didn't make do_coredump
clear group_stop_count because doing it with the appropriate ordering and
locking doesn't fit the organization that code.

Mounting a non-affs filesystem as affs crashes the kernel.
The reason is the
	sbi = kmalloc(sizeof(struct affs_sb_info), GFP_KERNEL);
	memset(sbi, 0, sizeof(*AFFS_SB));
where the second sizeof is 1, so that sbi is not zeroed at all.

Also, avoid a warning for printk of sector_t in amigaffs.h.

Previously, we only honored barriers wrt merging. Really honor them now,
move all pending requests to dispatch list and add the hard barrier at
the back.

gen-asm-offsets, the most common user of the new filechk function, needs
to be fed input from $< (the first prerequisite).

Patch from Adrian Bunk <bunk@fs.tum.de>

It would be nice if everyone would try to compile the patched files
before submitting patches...

raid0 doesn't have a thread, so md_wakeup_thread() derefs NULL.

Neil may end up doing this differently, but meanwhile....

Patch from Roman Zippel <zippel@linux-m68k.org>

- remove lock_kernel() (It was buggy too - there are at present two missing
  unlock_kernel()s)

- fixes a bitmap corruption problem.

From latest -aa kernels.

Patch from: Suparna Bhattacharya <suparna@in.ibm.com>

Just an obvious fix.
The kiocbClearX macros were doing a set_bit !
They should be calling clear_bit.
Ran into this now that I'm actually using kiocbClearKicked.

Patch from Alex Tomas <bzzz@tmi.comex.ru>

There is a logic error in ext2_new_block().  If we manage to reserve some
blocks in the final blockgroup, local variable `bit' will be equal to
sbi->s_groups_count and we erroneously assume that the allocation failed.

Fix that up by testing local variable `group_alloc' instead.