[PATCH] CONFIG_PREEMPT fix of do_debug()

If CONFIG_PREEMPT is enabled, and the kernel is preempted just before
do_debug() has a chance to save the debug register values, DR6 could be
read from the wrong CPU.

It is exactly the same problem as reading %cr2 in the page fault
handler.  Same fix: make the handler a interrupt gate, and enable
interrupts only once safe.

[PATCH] Fix compile warning for 'sys_exit_group'

sys_exit_group() doesn't return any value, and obviously cannot.

So don't make the compiler unhappy about it by claiming it does.

[PATCH] Fix Alt-SysRQ-T status, and comment

Fix wrong order of process status. It's

#define TASK_RUNNING            0
#define TASK_INTERRUPTIBLE      1
#define TASK_UNINTERRUPTIBLE    2
#define TASK_STOPPED            4
#define TASK_ZOMBIE             8
#define TASK_DEAD               16

but SysRQ printout routines switch stopped and zombie around.

So, for one more time, here's another mailing of the same patch to fix
this brokenness.  In addition, fix the wrong comment in fs/proc/array.c

More signal handling fixups for the threaded signal fix upheavals.

This fixes the signal code to not wake up threads with blocked signals,
especially noticeable with kernel threads that may not be able to handle
signals at all.

We also don't unnecessarily wake processes in TASK_UNINTERRUPTIBLE.

[PATCH] missing sound include file

Sound drivers need <linus/interrupt.h> for tasklets

ALSA update
  - emu10k1 - fixed makefile to not build synth module when emu10k1 is not selected

ALSA update
  - cmipci driver cleanups (ac3 & surround)
  - replaced snd_dma_residue() with snd_dma_pointer()
  - GCC 3.3 warnings removal
  - timer interface
    - recoded using tasklet
    - improved slave timer locking (should be much faster)
    - added async support
  - improved ioctl32 wrapper functions
  - fixed Makefile problems (synth modules were build for not selected driver)
  - AC97 codec
    - improved SPSA control
    - moved reset function outside the main init code
    - improved ALC650 initialization
  - USB driver
    - added quirk for Roland XV-2020

[PATCH] TASK_STOPPED wakeup cleanup

For handle_stop_signal to do the special case for SIGKILL and have it
work right in all SMP cases (without changing all the existing ptrace
stops), it needs to at least set TIF_SIGPENDING on each thread before
resuming it.

handle_stop_signal addresses a related race for SIGCONT by setting
TIF_SIGPENDING already, so having SIGKILL handled the same way makes
sense.

Now it seems pretty clean to have handle_stop_signal resume threads for
SIGKILL, and have on SIGKILL special case in group_send_sig_info.

There is also an SMP race issue with cases like do_syscall_trace, i.e.
TASK_STOPPED state set without holding the siglock.  So I think
handle_stop_signal should call wake_up_process unconditionally.

[PATCH] signal locking update

Accomodate the signal locking moving from "tsk->sig" to "tsk->sighand".

Hand merge

Split up "struct signal_struct" into "signal" and "sighand" parts.

This is required to get make the old LinuxThread semantics work
together with the fixed-for-POSIX full signal sharing. A traditional
CLONE_SIGHAND thread (LinuxThread) will not see any other shared
signal state, while a new-style CLONE_THREAD thread will share all
of it.

This way the two methods don't confuse each other.

Don't special-case SIGKILL/SIGSTOP - the blocking masks should
already take care of it.

This fixes kernel threads that _do_ block SIGKILL/STOP.

[PATCH] Fix possible uninitialised variable in vma merging code

Spotted by davem.  Strange that it ever worked.  Don't know why the compiler
didn't warn...

[PATCH] do_sigaction locking cleanup

This changes do_sigaction to avoid read_lock(&tasklist_lock) on every
call.  Only in the fairly uncommon cases where it's really needed will
it take that lock (which requires unlocking and relocking the siglock
for locking order).

I also changed the ERESTARTSYS added in my earlier patch to ERESTARTNOINTR.
That is an "instantaneous" case, and there is no reason to have it possibly
return EINTR if !SA_RESTART (which AFAIK sigaction never could before, and
it might not be kosher by POSIX); rollback is always better.

[PATCH] SA_NOCLDWAIT now supported - update comments

This patch removes all the comments on the SA_NOCLDWAIT definitions,
since SA_NOCLDWAIT is fully supported now.

[PATCH] Spelling fixes for consistent, dependent, persistent

This fixes the following common misspellings and their variants.

  consistant -> consistent
  dependant  -> dependent
  persistant -> persistent

Merge

Merge

[PATCH] exit_notify/do_exit cleanup

Here is a cleanup moving the new pending thread signal check into
exit_notify.

I also made exit_notify and do_exit consistent in using the saved tsk
variable instead of current, as most of do_exit already does.

Hand-merge with Ingo's changes

Signal handling bugs for thread exit + ptrace

Add PTRACE_O_TRACEVFORKDONE and PTRACE_O_TRACEEXIT facilities.

[PATCH] missing include in pci-sysfs.c

Add a missing include for those pesky S_IRUGO thingys.

[PATCH] 2.5.59 : drivers/media/video/bt819.c

This patch for bt819.c addresses buzilla bug #169 (compile error).

[PATCH] 2.5.59 : drivers/media/video/saa7185.c

This patch to saa7185 to resolves buzilla bug #168 (compile error).  It
has been sent to l-k and has received no objections.

[PATCH] 2.5.59 : drivers/media/video/bt856.c

This fixes a bt856.c compile error.  The driver now compiles.  Its a
straightforward patch and have emailed l-k and no objections have been
reported.

[PATCH] fix leaks in vxfs_read_fshead()

The Stanford checker disclose that vxfs_read_fshead was missing any
unwinding in the error cases..

[PATCH] Doc fix

[PATCH] Remove dead code

In struct char_dev the fields openers and sem are unused.
The file char_dev.c claims that it is called differently.

[PATCH] revert extra sendfile security hook patch

hm.  It seems that I sent this patch twice.

After resyncing with your tree I go through and try to reapply all the sent
patches, throwing out the ones which get a lot of rejects.  Just to make sure
that everything got through OK.

But it appears that that particular patch happily applied on top of itself,
so I assumed it was not applied...

[PATCH] Make sys_wait4() more readable

I cleaned up sys_wait4; it was straightforward and I think a definite
improvement.  While at it, I noticed that one of the races I fixed in the
TASK_STOPPED case actually can happen earlier.  Between read_unlock and
write_lock_irq, another thread could reap the process and make P invalid,
so now I do get_task_struct before read_unlock and then the existing race
checks catch all scenarios.

Aside from the aforementioned race tweak, the code should be the same as
in the previous patch (that Ingo and I have tested more thoroughly)
modulo being moved into functions and some reformatting and comment
changes.

Oh, my old patch had one case where it failed to retake the read lock after
a race bailout that I just noticed reading over it.  That's fixed too.

These exit fixes were something I noticed incidentally and spent less time
on than the signals changes.  Another few passes of eyeballs over them are
certainly warranted.  (In particular, there are code paths like that one
that check for specific races that have probably never been seen in
practice, so those code paths have never run once.)

[PATCH] Spelling fixes

OK, here is the diff against 2.5.59-bk2, now up to 880 lines due to an
additional misspelling which crept in the -bk2 snapshot.

Fixes 'seperate' -> 'separate' and 'definate' -> 'definite'.

Kernal codrs cna't spel.

[PATCH] Broken CLEAR_BITMAP() macro

The CLEAR_BITMAP() macro in include/linux/types.h is broken and doesn't
round the bitmap size to the proper 'long' boundary.

This fixes it by creating a macro BITS_TO_LONGS that just rounds a
number of bits up to the closest number of unsigned longs.  This makes
the DECLARE & CLEAR _BITMAP macros more readable and fixes the bug.

[PATCH] fix megaraid driver compile error

This moves access of the host element to device since host has been
removed from struct scsi_cmnd.

[PATCH] signal-fixes-2.5.59-A4

this is the current threading patchset, which accumulated up during the
past two weeks. It consists of a biggest set of changes from Roland, to
make threaded signals work. There were still tons of testcases and
boundary conditions (mostly in the signal/exit/ptrace area) that we did
not handle correctly.

Roland's thread-signal semantics/behavior/ptrace fixes:

 - fix signal delivery race with do_exit() => signals are re-queued to the
   'process' if do_exit() finds pending unhandled ones. This prevents
   signals getting lost upon thread-sys_exit().

 - a non-main thread has died on one processor and gone to TASK_ZOMBIE,
   but before it's gotten to release_task a sys_wait4 on the other
   processor reaps it.  It's only because it's ptraced that this gets
   through eligible_child.  Somewhere in there the main thread is also
   dying so it reparents the child thread to hit that case.  This means
   that there is a race where P might be totally invalid.

 - forget_original_parent is not doing the right thing when the group
   leader dies, i.e. reparenting threads to init when there is a zombie
   group leader.  Perhaps it doesn't matter for any practical purpose
   without ptrace, though it makes for ppid=1 for each thread in core
   dumps, which looks funny. Incidentally, SIGCHLD here really should be
   p->exit_signal.

 - one of the gdb tests makes a questionable assumption about what kill
   will do when it has some threads stopped by ptrace and others running.

exit races:

1. Processor A is in sys_wait4 case TASK_STOPPED considering task P.
   Processor B is about to resume P and then switch to it.

   While A is inside that case block, B starts running P and it clears
   P->exit_code, or takes a pending fatal signal and sets it to a new
   value. Depending on the interleaving, the possible failure modes are:
        a. A gets to its put_user after B has cleared P->exit_code
           => returns with WIFSTOPPED, WSTOPSIG==0
        b. A gets to its put_user after B has set P->exit_code anew
           => returns with e.g. WIFSTOPPED, WSTOPSIG==SIGKILL

   A can spend an arbitrarily long time in that case block, because
   there's getrusage and put_user that can take page faults, and
   write_lock'ing of the tasklist_lock that can block.  But even if it's
   short the race is there in principle.

2. This is new with NPTL, i.e. CLONE_THREAD.
   Two processors A and B are both in sys_wait4 case TASK_STOPPED
   considering task P.

   Both get through their tests and fetches of P->exit_code before either
   gets to P->exit_code = 0.  => two threads return the same pid from
   waitpid.

   In other interleavings where one processor gets to its put_user after
   the other has cleared P->exit_code, it's like case 1(a).

3. SMP races with stop/cont signals

   First, take:

        kill(pid, SIGSTOP);
        kill(pid, SIGCONT);

   or:

        kill(pid, SIGSTOP);
        kill(pid, SIGKILL);

   It's possible for this to leave the process stopped with a pending
   SIGCONT/SIGKILL.  That's a state that should never be possible.
   Moreover, kill(pid, SIGKILL) without any repetition should always be
   enough to kill a process.  (Likewise SIGCONT when you know it's
   sequenced after the last stop signal, must be sufficient to resume a
   process.)

4. take:

        kill(pid, SIGKILL);     // or any fatal signal
        kill(pid, SIGCONT);     // or SIGKILL

    it's possible for this to cause pid to be reaped with status 0
    instead of its true termination status.  The equivalent scenario
    happens when the process being killed is in an _exit call or a
    trap-induced fatal signal before the kills.

plus i've done stability fixes for bugs that popped up during
beta-testing, and minor tidying of Roland's changes:

 - a rare tasklist corruption during exec, causing some very spurious and
   colorful crashes.

 - a copy_process()-related dereference of already freed thread structure
   if hit with a SIGKILL in the wrong moment.

 - SMP spinlock deadlocks in the signal code

this patchset has been tested quite well in the 2.4 backport of the
threading changes - and i've done some stresstesting on 2.5.59 SMP as
well, and did an x86 UP testcompile + testboot as well.

[PATCH] ips driver 4/4: error messages

This small patch does 2 things.  It reworks the firmware/driver
versioning messages to make them more understandable, and it
fixes one case where the 64bit addressing changes caused
error/success to not be properly reported to the serveraid tools.

[PATCH] ips driver 3/4: 64bit dma addressing

This large patch adds support for using 64bit addressing.

Special thanks goes to Mike Anderson who did the initial
versions of this patch.

[PATCH] ips driver 2/4: initialization reordering

This large patch reworks much of the adapter initialization
code.

It splits the scsi initialization code from the pci
initialization.  It adds support for working with some
future cards.  It also removes the use of multiple pci_driver
registrations and instead does its own adapter ordering.

[PATCH] ips driver 1/4: fix struct length and remove dead code

This small patch fixes the length of the IPS_ENQ
struct.  It was too short which can cause the adapter
to write beyond the the end of the struct during
driver initialization and corrupt part of memory.

Merge http://linux-scsi.bkbits.net/scsi-for-linus-2.5
into home.transmeta.com:/home/torvalds/v2.5/linux

Merge raven.il.steeleye.com:/home/jejb/BK/scsi-misc-2.5
into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5

[PATCH] coding style updates for scsi_lib.c

I just couldn't see the mess anymore..  Nuke the ifdefs and use sane
variable names.  Some more small nitpicks but no behaviour changes at
all.

[PATCH] 2.5.59 add two help texts to drivers_scsi_Kconfig

From:  Steven Cole <elenstev@mesatop.com>

  Here are some help texts from 2.4.21-pre3 Configure.help which are
  needed in 2.5.59 drivers/scsi/Kconfig.

  Steven

[PATCH] [patch, 2.5] scsi_qla1280.c free on error path

From:  Marcus Alanen <maalanen@ra.abo.fi>

  Remove check_region in favour of request_region. Free resources
  properly on error path. Horribly subtle ioremap/iounmap lurks here I
  think, in qla1280_pci_config(), which the below patch should take care
  of.

  I'm wondering if there couldn't / shouldn't be a better way to
  allocate resources. Obviously lots of drivers have broken error paths.
  Is this even necessary?

  Marcus

  #
  # create_patch: qla1280_release_on_error_path-2002-12-08-A.patch
  # Date: Sun Dec  8 22:32:33 EET 2002
  #

[SCSI] Remove host_active

It isn't used anywhere anymore

Merge http://linux-acpi.bkbits.net/linux-acpi
into home.transmeta.com:/home/torvalds/v2.5/linux

ACPI: Enable compilation w/o cpufreq

[PATCH] quota memleak

The Stanford Checker found a memleak.

Merge bk://kernel.bkbits.net/vojtech/x86-64
into home.transmeta.com:/home/torvalds/v2.5/linux

x86-64: Minor fixes to make the kernel compile and remove warnings.

[PATCH] Fix signed use of i_blocks in ext3 truncate

Patch from "Stephen C. Tweedie" <sct@redhat.com>

Fix "h_buffer_credits<0" assert failure during truncate.

The bug occurs when the "i_blocks" count in the file's inode overflows
past 2^31.  That works fine most of the time, because i_blocks is an
unsigned long, and should go up to 2^32; but there's a place in truncate
where ext3 calculates the size of the next transaction chunk for the
delete, and that mistakenly uses a signed long instead.  Because the
huge i_blocks gets cast to a negative value, ext3 does not reserve
enough credits for the transaction and the above error results.

This is usually only possible on filesystems corrupted for other
reasons, but it is reproducible if you create a single, non-sparse file
larger than 1TB on ext3 and then try to delete it.

[PATCH] CPU Hotplug mm/slab.c CPU_UP_CANCELED fix

Patch from Manfred Spraul.

Fixes a bug which was exposed by Zwane's hotplug CPU work.  The
cache_cache.array pointer is initially given a temp bootstrap area, which is
later converted over to the final value after the CPU is brought up.

But if slab is enhanced to permit cancellation of a CPU bringup, this pointer
ends up pointing at stale memory.  So reinitialise it by hand when
kmem_cache_init() is run.

[PATCH] spinlock debugging on uniprocessors

Patch from Manfred Spraul <manfred@colorfullife.com>

This enables spinlock debuggng on uniprocessor builds, under
CONFIG_DEBUG_SPINLOCK.

The reason I want this is that one day we'll need to pull out the debugging
support from the timer code which detects uninitialised timers.  And once
that has gone, uniprocessor developers and testers have no way of detecting
uninitialised timers - there will be mysterious deadlocks on SMP machines.
And there will surely be more uninitialised timers

The patch also removes the last pieces of the support for including
<asm/spinlock.h> directly.  Doesn't work since (IIRC) 2.3.x

[PATCH] mm/mremap.c whitespace cleanup

- Not everyone uses 160-column xterms.

- Coding style consistency

[PATCH] hugetlb mremap fix

If you attempt to perform a relocating 4k-aligned mremap and the new address
for the map lands on top of a hugepage VMA, do_mremap() will attempt to
perform a 4k-aligned unmap inside the hugetlb VMA.  The hugetlb layer goes
BUG.

Fix that by trapping the poorly-aligned unmap attempt in do_munmap().
do_remap() will then fall through without having done anything to the place
where it tests for a hugetlb VMA.

It would be neater to perform these checks on entry to do_mremap(), but that
would incur another VMA lookup.

Also, if you attempt to perform a 4k-aligned and/or sized munmap() inside a
hugepage VMA the same BUG happens.  This patch fixes that too.

This all means that an mremap attempt against a hugetlb area will fail, but
only after having unmapped the source pages.  That's a bit messy, but
supporting hugetlb mremap doesn't seem worth it, and completely disallowing
it will add overhead to normal mremaps.

[PATCH] Fix hugetlb_vmtruncate_list()

This function is quite wrong - has an "=" where it should have a "-" and
confuses PAGE_SIZE and HPAGE_SIZE in its address and file offset arithmetic.

[PATCH] ia32 hugetlb cleanup

- whitespace

- remove unneeded spinlocking no-op.

[PATCH] Fix hugetlbfs faults

If the underlying mapping was truncated and someone references the
now-unmapped memory the kernel will enter handle_mm_fault() and will start
instantiating PAGE_SIZE pte's inside the hugepage VMA.  Everything goes
generally pear-shaped.

So trap this in handle_mm_fault().  It adds no overhead to non-hugepage
builds.

Another possible fix would be to not unmap the huge pages at all in truncate
- just anonymise them.

But I think we want full ftruncate semantics for hugepages for management
purposes.

[PATCH] Give all architectures a hugetlb_nopage().

If someone maps a hugetlbfs file, then truncates it, then references the part
of the mapping outside the truncation point, they take a pagefault and we end
up hitting hugetlb_nopage().

We want to prevent this from ever happening.  This patch just makes sure that
all architectures have a goes-BUG hugetlb_nopage() to trap it.

[PATCH] hugetlbfs cleanups

- Remove quota code.

- Remove extraneous copy-n-paste code from truncate: that's only for
  physically-backed filesystems.

- Whitespace changes.

[PATCH] hugetlbfs i_size fixes

We're expanding hugetlbfs i_size in the wrong place.  If someone attempts to
mmap more pages than are available, i_size is updated to reflect the
attempted mapping size.

So set i_size only when pages are successfully added to the mapping.

i_size handling at truncate time is still a bit wrong - if the mapping has
pages at (say) page offset 100-200 and the mappng is truncated to (say) page
offset 50, i_size should be set to zero.  But it is instead set to
50*HPAGE_SIZE.  That's harmless.

[PATCH] hugetlbfs: fix truncate

- Opening a hugetlbfs file O_TRUNC calls the generic vmtruncate() functions
  and nukes the kernel.

  Give S_ISREG hugetlbfs files a inode_operations, and hence a setattr
  which know how to handle these files.

- Don't permit the user to truncate hugetlbfs files to sizes which are not
  a multiple of HPAGE_SIZE.

- We don't support expanding in ftruncate(), so remove that code.

[PATCH] get_unmapped_area for hugetlbfs

Having to specify the mapping address is a pain.  Give hugetlbfs files a
file_operations.get_unmapped_area().

The implementation is in hugetlbfs rather than in arch code because it's
probably common to several architectures.  If the architecture has special
needs it can define HAVE_ARCH_HUGETLB_UNMAPPED_AREA and go it alone.  Just
like HAVE_ARCH_UNMAPPED_AREA.

[PATCH] convert hugetlb code to use compound pages

The odd thing about hugetlb is that it maintains its own freelist of pages.
And it has to do that, else it would trivially run out of pages due to buddy
fragmetation.

So we we don't want callers of put_page() to be passing those pages
to __free_pages_ok() on the final put().

So hugetlb installs a destructor in the compound pages to point at
free_huge_page(), which knows how to put these pages back onto the free list.

Also, don't mark hugepages as all PageReserved any more.  That's preenting
callers from doing proper refcounting.  Any code which does a user pagetable
walk and hits part of a hugepage will now handle it transparently.

[PATCH] Infrastructure for correct hugepage refcounting

We currently have a problem when things like ptrace, futexes and direct-io
try to pin user pages.  If the user's address is in a huge page we're
elevting the refcount of a constituent 4k page, not the head page of the
high-order allocation unit.

To solve this, a generic way of handling higher-order pages has been
implemented:

- A higher-order page is called a "compound page".  Chose this because
  "huge page", "large page", "super page", etc all seem to mean different
  things to different people.

- The first (controlling) 4k page of a compound page is referred to as the
  "head" page.

- The remaining pages are tail pages.

All pages have PG_compound set.  All pages have their lru.next pointing at
the head page (even the head page has this).

The head page's lru.prev, if non-zero, holds the address of the compound
page's put_page() function.

The order of the allocation is stored in the first tail page's lru.prev.
This is only for debug at present.  This usage means that zero-order pages
may not be compound.

The above relationships are established for _all_ higher-order pages in the
page allocator.  Which has some cost, but not much - another atomic op during
fork(), mainly.

This functionality is only enabled if CONFIG_HUGETLB_PAGE, although it could
be turned on permanently.  There's a little extra cost in get_page/put_page.

These changes do not preclude adding compound pages to the LRU in the future
- we can add a new page flag to the head page and then move all the
additional data to the first tail page's lru.next, lru.prev, list.next,
list.prev, index, private, etc.

[PATCH] give hugetlbfs a set_page_dirty a_op

Seems that nobody has tested direct IO into hugetlb pages yet.  The VFS gets
upset about running set_page_dirty() against a non-uptodate page.

So give hugetlbfs inodes a private no-op ->set_page_dirty() to isolate them
from all that.

[PATCH] pte_chain_alloc fixes

There are several places in which the return value from pte_chain_alloc() is
not being checked, and one place in which a GFP_KERNEL allocatiopn is
happening inside spinlock.

[PATCH] loop inefficiency fix

Patch from Hugh Dickins <hugh@veritas.com>

The loop driver's loop over elements of bi_io_vec is in lo_send and
lo_receive: iterating that same transfer bi_vcnt times at the level above is,
er, excessive.  (And no need to increment bi_idx here.)

[PATCH] default_idle micro-optimisation

Patch from rwhron@earthlink.net

Micro-optimization of default_idle from -aa.  current_cpu_data.hlt_works_ok
is only false for some old 386/486 pcs.

[PATCH] Optimise follow_page() for page-table-based hugepages

ia32 and others can determine a page's hugeness by inspecting the pmd's value
directly.  No need to perform a VMA lookup against the user's virtual
address.

This patch ifdef's away the VMA-based implementation of
hugepage-aware-follow_page for ia32 and replaces it with a pmd-based
implementation.

The intent is that architectures will implement one or the other.  So the architecture either:

1: Implements hugepage_vma()/follow_huge_addr(), and stubs out
   pmd_huge()/follow_huge_pmd() or

2: Implements pmd_huge()/follow_huge_pmd(), and stubs out
   hugepage_vma()/follow_huge_addr()

[PATCH] Fix futexes in huge pages

Using a futex in a large page causes a kernel lockup in __pin_page() -
because __pin_page's page revalidation uses follow_page(), and follow_page()
doesn't work for hugepages.

The patch fixes up follow_page() to return the appropriate 4k page for
hugepages.

This incurs a vma lookup for each follow_page(), which is considerable
overhead in some situations.  We only _need_ to do this if the architecture
cannot determin a page's hugeness from the contents of the PMD.

So this patch is a "reference" implementation for, say, PPC BAT-based
hugepages.

[PATCH] ia32 IRQ distribution rework

Patch from "Kamble, Nitin A" <nitin.a.kamble@intel.com>

Hello All,

  We were looking at the performance impact of the IRQ routing from
the 2.5.52 Linux kernel. This email includes some of our findings
about the way the interrupts are getting moved in the 2.5.52 kernel.
Also there is discussion and a patch for a new implementation. Let
me know what you think at nitin.a.kamble@intel.com

Current implementation:
======================
We have found that the existing implementation works well on IA32
SMP systems with light load of interrupts. Also we noticed that it
is not working that well under heavy interrupt load conditions on
these SMP systems. The observations are:

* Interrupt load of each IRQ is getting balanced on CPUs independent
of load of other IRQs. Also the current implementation moves the
IRQs randomly. This works well when the interrupt load is light. But
we start seeing imbalance of interrupt load with existence of
multiple heavy interrupt sources. Frequently multiple heavily loaded
IRQs gets moved to a single CPU while other CPUs stay very lightly
loaded. To achieve a good interrupts load balance, it is important to
consider the load of all the interrupts together.
    This further can be explained with an example of 4 CPUs and 4
heavy interrupt sources. With the existing random movement approach,
the chance of each of these heavy interrupt sources moving to separate
CPUs is: (4/4)*(3/4)*(2/4)*(1/4) = 3/16. It means 13/16 = 81.25% of
the time the situation is, some CPUs are very lightly loaded and some
are loaded with multiple heavy interrupts. This causes the interrupt
load imbalance and results in less performance. In a case of 2 CPUs
and 2 heavily loaded interrupt sources, this imbalance happens
1/2 = 50% of the times. This issue becomes more and more severe with
increasing number of heavy interrupt sources.

* Another interesting observation is: We cannot see the imbalance
of the interrupt load from /proc/interrupts. (/proc/interrupts shows
the cumulative load of interrupts on all CPUs.) If the interrupt load
is imbalanced and this imbalance is getting rotated among CPUs
continuously, then /proc/interrupts will still show that the interrupt
load is going to processors very evenly. Currently at the frequency
(HZ/50) at which IRQs are moved across CPUs, it is not possible to
see any interrupt load imbalance happening.

* We have also found that, in certain cases the static IRQ binding
performs better than the existing kernel distribution of interrupt
load. The reason is, in a well-balanced interrupt load situations,
these interrupts are unnecessarily getting frequently moved across
CPUs. This adds an extra overhead; also it takes off the CPU cache
warmth benefits.
  This came out from the performance measurements done on a 4-way HT
(8 logical processors) Pentium 4 Xeon system running 8 copies of
netperf. The 4 NICs in the system taking different IRQs generated
sizable interrupt load with the help of connected clients.

Here the netperf transactions/sec throughput numbers observed are:

IRQs nicely manually bound to CPUs: 56.20K
The current kernel implementation of IRQ movement: 50.05K
 -----------------------
 The static binding of IRQs has performed 12.28% better than the
current IRQ movement implemented in the kernel.

* The current implementation does not distinguish siblings from the
HT (Hyper-Threading(tm)) enabled CPUs. It will be beneficial to
balance the interrupt load with respect to processor packages first,
and then among logical CPUs inside processor packages.
  For example if we have 2 heavy interrupt sources and 2 processor
packages (4 logical CPUs); Assigning both the heavy interrupt sources
in different processor packages is better, it will use different
execution resources from the different processor packages.

New revised implementation:
==========================
We also have been working on a new implementation. The following
points are in main focus.

* At any moment heavily loaded IRQs are distributed to different
CPUs to achieve as much balance as possible.

* Lightly loaded interrupt sources are ignored from the load
balancing, as they do not cause considerable imbalance.

* When the heavy interrupt sources are balanced, they are not moved
around. This also helps in keeping the CPU caches warm.

* It has been made HT aware. While distributing the load, the load
on a processor package to which the logical CPUs belong to is also
considered.

* In the situations of few (lesser than num_cpus) heavy interrupt
sources, it is not possible to balance them evenly. In such case
the existing code has been reused to move the interrupts. The
randomness from the original code has been removed.

* The time interval for redistribution has been made flexible. It
varies as the system interrupt load changes.

* A new kernel_thread is introduced to do the load balancing
calculations for all the interrupt sources. It keeps the balanace_maps
ready for interrupt handlers, keeping the overhead in the interrupt
handling to minimum.

* It allows the disabling of the IRQ distribution from the boot loader
command line, if anybody wants to do it for any reason.

* The algorithm also takes into account the static binding of
interrupts to CPUs that user imposes from the
/proc/irq/{n}/smp_affinity interface.

Throughput numbers with the netperf setup for the new implementation:

Current kernel IRQ balance implementation: 50.02K transactions/sec
The new IRQ balance implementation: 56.01K transactions/sec
 ---------------------
  The performance improvement on P4 Xeon of 11.9% is observed.

The new IRQ balance implementation also shows little performance
improvement on P6 (Pentium II, III) systems.

On a P6 system the netperf throughput numbers are:
Current kernel IRQ balance implementation: 36.96K transactions/sec
The new IRQ balance implementation: 37.65K transactions/sec
 ---------------------
Here the performance improvement on P6 system of about 2% is observed.

 ---------------------

Andrew Theurer <habanero@us.ibm.com> did some testing of this patch on a quad
P4:

I got a chance to run the NetBench benchmark with your patch on 2.5.54-mjb2
kernel.  NetBench measures SMB/CIFS performance by using several SMB
clients  (in this case 44 Windows 2000 systems), sending SMB requests to a
Linux  server running Samba 2.2.3a+sendfile.  Result is in throughput,
Mbps.   Generally the network traffic on the server is 60% recv, 40% tx.

I believe we have very similar systems.  Mine is a 4 x 1.6 GHz, 1 MB L3 P4
Xeon with 4 GB DDR memory (3.2 GB/sec I believe).  The chipset is "Summit".
 I also have more than one Intel e1000 adapters.

I decided to run a few configurations, first with just one adapter, with
and  without HT support in the kernel (acpi=off), then add another adapter
and  test again with/without HT.

Here are the results:

4P, no HT, 1 x e1000, no kirq: 1214 Mbps, 4% idle
4P, no HT, 1 x e1000, kirq: 1223 Mbps, 4% idle, +0.74%

I suppose we didn't see much of an improvement here because we never run
into  the situation where more than one interrupt with a high rate is
routed to a  single CPU on irq_balance.

4P, HT, 1 x e1000, no kirq: 1214 Mbps, 25% idle
4P, HT, 1 x e1000, kirq: 1220 Mbps, 30% idle, +0.49%

Again, not much of a difference just yet, but lots of idle time.  We may
have  reached the limit at which one logical CPU can process interrupts for
an  e1000 adapter.  There are other things I can probably do to help this,
like  int delay, and NAPI, which I will get to eventually.

4P, HT, 2 x e1000, no kirq: 1269 Mbps, 23% idle
4P, HT, 2 x e1000, kirq: 1329 Mbps, 18% idle +4.7%

OK, almost 5% better!  Probably has to do with a couple of things; the fact
that your code does not route two different interrupts to the same
core/different logical cpus (quite obvious by looking at /proc/interrupts),
and that more than one interrupt does not go to the same cpu if possible.
I  suspect irq_balance did some of those [bad] things some of the time, and
we  observed a bottleneck in int processing that was lower than with kirq.

I don't think all of the idle time is because of a int processing
bottleneck.   I'm just not sure what it is yet :)  Hopefully something will
become obvious  to me...

Overall I like the way it works, and I believe it can be tweaked to work
with  NUMA when necessary.  I hope to have access to a specweb system on a
NUMA box  soon, so we can verify that.

[PATCH] Fix SMP race betwen __sync_single_inode and

Patch from Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>

there's a SMP race condition between __sync_single_inode (or __sync_one on
2.4.20) and __mark_inode_dirty. __mark_inode_dirty doesn't take inode
spinlock. As we know -- unless you take a spinlock or use barrier,
processor can change order of instructions.

CPU 1

modify inode
(but modifications are in cpu-local
buffer and do not go to bus)

calls
__mark_inode_dirty
it sees I_DIRTY and exits immediatelly
CPU 2
takes spinlock
calls __sync_single_inode
inode->i_state &= ~I_DIRTY
writes the inode (but does not see
modifications by CPU 1 yet)

CPU 1 flushes its write buffer to the bus
inode is already written, clean, modifications
done by CPU1 are lost

The easiest fix would be to move the test inside spinlock in
__mark_inode_dirty; if you do not want to suffer from performance loss,
use the attached patches that use memory barriers to ensure ordering of
reads and writes.

[PATCH] Restore LSM hook calls to sendfile

Patch from "Stephen D. Smalley" <sds@epoch.ncsc.mil>

This patch restores the LSM hook calls in sendfile to 2.5.59.  The hook was
previously added as of 2.5.29 but the hook calls in sendfile were
subsequently lost as a result of the sendfile rewrite as of 2.5.30.

[PATCH] JBD Documentation

Patch from Roger Gammans <roger@computer-surgery.co.uk>

Adds lots of API documentation to the JBD layer.

[PATCH] Updated Documentation/kernel-parameters.txt

Patch from Petr Baudis <pasky@ucw.cz>

this patch (against 2.5.59) updates Documentation/kernel-parameters.txt to
the (more-or-less; I certainly missed some parameters) current state of
kernel.  Note also that I will probably send up another update after few
further kernel releases..

[PATCH] Remove most of the blk_run_queues() calls

We don't need these with self-unplugging queues.

The patch also contains a couple of microopts suggested by Andrea: we
don't need to run sync_page() if the page just came unlocked.

[PATCH] self-unplugging request queues

The patch teaches a queue to unplug itself:

a) if is has four requests OR
b) if it has had plugged requests for 3 milliseconds.

These numbers may need to be tuned, although doing so doesn't seem to
make much difference.  10 msecs works OK, so HZ=100 machines will be
fine.

Instrumentation shows that about 5-10% of requests were started due to
the three millisecond timeout (during a kernel compile).  That's
somewhat significant.  It means that the kernel is leaving stuff in the
queue, plugged, for too long.  This testing was with a uniprocessor
preemptible kernel, which is particularly vulnerable to unplug latency
(submit some IO, get preempted before the unplug).

This patch permits the removal of a lot of rather lame unplugging in
page reclaim and in the writeback code, which kicks the queues
(globally!) every four megabytes to get writeback underway.

This patch doesn't use blk_run_queues().  It is able to kick just the
particular queue.

The patch is not expected to make much difference really, except for
AIO.  AIO needs a blk_run_queues() in its io_submit() call.  For each
request.  This means that AIO has to disable plugging altogether,
unless something like this patch does it for it.  It means that AIO
will unplug *all* queues in the machine for every io_submit().  Even
against a socket!

This patch was tested by disabling blk_run_queues() completely.  The
system ran OK.

The 3 milliseconds may be too long.  It's OK for the heavy writeback
code, but AIO may want less.  Or maybe AIO really wants zero (ie:
disable plugging).  If that is so, we need new code paths by which AIO
can communicate the "immediate unplug" information - a global unplug is
not good.

To minimise unplug latency due to user CPU load, this patch gives keventd
`nice -10'.  This is of course completely arbitrary.  Really, I think keventd
should be SCHED_RR/MAX_RT_PRIO-1, as it has been in -aa kernels for ages.

[PATCH] reiserfs v3 readpages support

Patch from Chris Mason <mason@suse.com>

The patch below is against 2.5.59, various forms have been floating
around for a while, and Andrew recently included this fixed version in
2.5.55-mm.  The end result is faster reads and writes for reiserfs.

This adds reiserfs support for readpages, along with a support func in
fs/mpage.c to deal with the reiserfs_get_block call sending back up to
date buffers with packed tails copied into them.

Most of the changes are to reiserfs_writepage, which still had many
2.4isms in the way it started io, dealt with errors and handled the bh
state bits.  I've also added an optimization so it only starts
transactions when we need to copy a packed tail into the btree or fill a
hole, instead of any time reiserfs_writepage hits an unmapped buffer.

[PATCH] BTTV build fix

Patch from Gerd Knorr <kraxel@bytesex.org>

bttv requires CONFIG_SOUND.

[PATCH] add back single_lun support

On Wed, Feb 05, 2003 at 05:14:00PM -0600, James Bottomley wrote:

> I don't see device_active getting set anywhere.
>
> shouldn't we just dump device_active in favour of a non-zero check of
> device_busy (it's all done under the queue lock, anyway).
>
> James

OK - once more.

This patch against the current scsi-misc-2.5 adds back the check for the
single_lun case and removes the unused device_active field.

I compiled and booted with this applied but don't have any devices (i.e.
CD ROM changer) for testing.

Merge http://jdike.stearns.org:5000/fixes-2.5
into home.transmeta.com:/home/torvalds/v2.5/linux

Merge http://jdike.stearns.org:5000/stack-2.5
into home.transmeta.com:/home/torvalds/v2.5/linux

Merge http://jdike.stearns.org:5000/skas-2.5
into home.transmeta.com:/home/torvalds/v2.5/linux

Merge http://jdike.stearns.org:5000/updates-2.5
into home.transmeta.com:/home/torvalds/v2.5/linux

sysfs: remember to add EXPORT_SYMBOL() for sysfs_update_file.

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

[PATCH] IBM PCI Hotplug: fix a load of memory leak errors found by the checker project.

[PATCH] IBM PCI Hotplug: fix memory leak found by checker project.

[PATCH] Compaq PCI Hotplug: fix checker memory leak bugs.

[PATCH] PCI Hotplug: memory leaks in acpiphp_glue

Here's the memory leaks patch for acpiphp_glue.c.

[PATCH] PCI:  put proper field sizes on sysfs files, and add class file.

[PATCH] pci patch for sysfs files

The patch is modeled after your method for creating files for usb. It
makes a single file for pci sysfs files (except for pool, which I haven't
touched yet). It also exposes more pci information to User Space
through sysfs. Finally, it removes the dependence on the proc pci code
for sysfs files.

[PATCH] PCI Hotplug: checker patches

Fixes problems found by the CHECKER program in the pci hotplug drivers

[PATCH] PCI Hotplug: moved the some stuff into the pci core

Moved functions from drivers/hotplug/pci_hotplug_util.c to
drivers/pci/hotplug.c, which is a better place for them.

[PATCH] PCI Hotplug: Make pci_hp_change_slot_info() work again

Relies on sysfs_update_file() to be present in the kernel.

[PATCH] sysfs: add sysfs_update_file() function.

[PATCH] PCI Hotplug: change pci_hp_change_slot_info() to take a hotplug_slot and not a string.

[PATCH] PCI Hotplug: Remove procfs stuff from pci_hotplug_core

Here is a little patch that remove procfs stuff in pci_hotplug_core.c
Remove /proc entry for pci_hotplug_core.

[PATCH] PCI Hotplug: Replace pcihpfs with sysfs.