This caused the system call code to test for the wrong number of
system calls, with resulting exciting results. 

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

	for 2.6.0.  The proper fix is to replace ia64_ni_syscall with
	sys_ni_syscall, but that would make the patch quite large, so
	we defer that till 2.6.1.

	restore_sigcontext().  Also update ia32 subsystem accordingly.

	in practice, but it's clearly wrong and just waiting there to
	get triggered...

Fix the creation of the /proc/net/bonding dir.
Patch is against 2.6.

Amir

This patch (against latest 2.6.0) is also waiting for almost a month.
It's already in 2.4 but is still very much needed for 2.6.

Old ifenslave versions (like the one in Red Hat 9) don't work with
the bonding module in the latest 2.6 kernel without it.

Amir

Original report and bug fix from: Amit Patel <patelamitv@yahoo.com>

The problem was a signed vs unsigned char problem when computing luns
for scanning.

From: Adrian Bunk <bunk@fs.tum.de>

Modular BINFMT_ELF doesn't build, and is pretty pathological anyway.

So just make it a boolean rather than a tristate.

From: Herbert Xu <herbert@gondor.apana.org.au>

The recent patch produces a message with no terminating newline on the
machine in question.  This is because one of the four bytes that you're
printing out is NUL.  The following patch avoids that problem.

From: Jeremy Higdon <jeremy@classic.engr.sgi.com>

I believe there is a bug in kernel/resource.c.

We (SGI sn2 I/O code) are using this for allocating dma map resources, and
we tracked failures we were seeing to find_resource().

The problem is that when testing bounds in the forever loop, the end bound
would be one higher than it should be if it gets set from another resource
(it's set to the proper value when it gets set from the root), causing
find_resource to return an invalid min/max when the requested size was one
greater than would fit between two existing resources.

From: Andreas Gruenbacher <agruen@suse.de>

64-bit pointer arithmetic bug in xattr code

The int offset is not enought to hold the difference between arbitraty
pointers on 64-bit machines.  Compute the offset of here and last inside
HDR(bh) instead.

From: James Cleverdon <jamesclv@us.ibm.com>

On summit-based machines the cpu_sibling_map data has been hosed for some
time.  I found out why in Intel's IA-32 Software Deveveopers' Manual Vol 2
under CPUID.  Looks like the value that cpuid returns is the one latched at
reset, and doesn't reflect any changes made by the BIOS later:

  * Local APIC ID (high byte of EBX)--this number is the 8-bit ID that
    is assigned to the local APIC on the processor during power up.  This
    field was introduced in the Pentium 4 processor.

Also, the code in init_intel was a bit overdesigned.  Until Intel releases
a chip with a non-power-of-2 sibling count on it, there's no point in all
that bit bashing.

From: Jun Sun <jsun@mvista.com>

It is needed for all those "__attribute_used__" etc to be valid.

Also, it seems that when compiling a file ending in ".S", gcc-2.95.3 does not
expand __GNUC__ at all.  This causes the compiler version check to fail when
building vsyscall.S.  So add __ASSEMBLY__ wrappers in there.

Fix a couple of problems which were introduced by a recent race fix in the
ext2 block allocator:

- if the allocation attempt raced, and lost the race then a new attempt is
  made.  But the earlier reservation must be put back first.

  Add a call to group_release_blocks() to fix this.

- if the filesystem is genuinely corrupted then the code as-is can get
  stuck in an infinite loop, thinking that a blockgroup has free blocks and
  then discovering that its bitmap is full.

  Fix this by baling out after having scanned all blockgroups twice.

  (Thanks Muli Ben-Yehuda <mulix@mulix.org> for spotting this).

From: Alex Tomas <alex@clusterfs.com>

If the ext3 inode allocator tries to claim an inode and fails because
another CPU got in there first it will then advance onto the next
blockgroup and try again.

Change it to advance onto the next inode within the same blockgroup
instead.

From: Jens Axboe <axboe@suse.de>

Print a runtime warning if ide-scsi is used on a cd device.

Modify the ide-scsi menuconfig help to reflect that ide-scsi should
not be used for cd burning.

If both ext2 and ext3 are built as modules there is nothing to pull
percpu_counter_mod() into the kernel build and the ext2 and ext3 modules do
not load.

So move percpu_counter_mod() out of lib.a.

It now has no callers.

From: Mingming Cao <cmm@us.ibm.com>

I found several bugs/issues in the ext2_new_inode() code:

1) The for loop variable "i" is used to save the inode offset.  In the
   case of failure, the loop variable could be crapped.  So it is possible
   to quit searching before looking at every block groups.

2) The number of free inodes in the selected group is possibly being
   miscalculated.  The counter is only decreased in the find_group_xx()
   functions for the initial selected group.  If the initial try failed,
   and succeed in finding a free inode in other group, the counter for that
   group will not to be decreased.

3) In case of the concurrent case, going back to find_group_xx()
   functions are unnecessary, it will only get the same group as before.

The following patch fixed those issues.  Ideas are stolen from
ext3_new_inode().

From: Zwane Mwaikambo <zwane@arm.linux.org.uk>

If the CPU doesn't support PSE we cannot use hugetlb pages.

From: Oleg Drokin <green@linuxhacker.ru>

reiserfs shouldn't be holding a ref against a buffer when running
set_blocksize(): it means that truncate_inode_pages() cannot free that page.

Which is not fatal - the page will drift aimlessly down the LRU until the VM
nails it.   But it's better this way.

From: Thomas Schlicter

sched_clock() will try to use the TSC even if the system is not using the TSC
as a time source.  It causes bad scheduling decisions and poor interactivity.

The problem was exhibited by the patch which uses ACPI PM as a time source,
but could also happen if the system is using the PIT.

From: Stephen Hemminger <shemminger@osdl.org>

The original problem all this is solving is that when NTP is slowing the clock
there existed real cases where time appeared to go backwards. Assuming NTP was
slowing the clock, then it would update the xtime by 999us at the next timer interrupt.
If a program read time three times:

A:	    xtime = t0
B: A+1000   xtime = t0 + 1000
C: B+1	    xtime = t0 + 999

To behave correctly C > B > A; but we were returning C < B

The code does have bug if we are losing clock interrupts.  The test for
lost interrupts needs to be after the interval clamp.

There's a window in this function where a wakeup can get lost.

From: Zwane Mwaikambo <zwane@arm.linux.org.uk>

gcc-3.2.2-5 miscompiles constant_test_bit().  Tweak it so the compiler gets
it right.  It cleans it up too!

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

We need to make the scan data unsigned, since we do

 	length = ((data[0] << 24) | (data[1] << 16) |
 		  (data[2] << 8) | (data[3] << 0));

and if data[3] is 0xff, this expression will always evaluate to
0xffffffff.  etcetera.

into hera.kernel.org:/home/davem/BK/net-2.5

Problem introduced by cset 1.1046.1.318

This is the PPC64 counterpart of the fix for the potential race in the
syscall restart code that has gone into other architectures.  It resets
current_thread_info()->restart_block.fn to do_no_syscall_restart in
the sigreturn code.

into home.osdl.org:/home/torvalds/v2.5/linux