into fidel.sfbay.redhat.com:/fidel/ity/rth/linux/linus-2.5

into are.twiddle.net:/home/rth/BK/linux-alpha-2.5

into are.twiddle.net:/home/rth/BK/linux-alpha-2.5

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

for the definition of unlikely().

	Next one in the series - this time it's ->unlink()...

1) proc/<pid>/fd readdir() has broken locking - sometimes it ends up with
task->files->file_lock locked.

2) missing variable definition in arch/s390x/kernel/linux32.c::cp_new_stat32().

Please, apply - the first one is really serious.

	BKL held around ->i_nlink changes in ext2/namei.c.  That makes
namei.c SMP-safe (dir.c already is).  BKL dropped around ext2_free_inode() -
it's already SMP-safe (the only place that needed BKL was DQUOT_FREE_INODE()
and it got BKL in the previous patch).

	BKL shifted into ->create().  lock_kernel()/unlock_kernel() added
in dquot_{alloc,free}_inode() - that makes {ext2,minix,sysv,ufs}_read_inode()
SMP-safe.

	ext2_read_inode() and ext2_update_inode() share large chunk
of code - getting a buffer_head with raw inode in it.
	Moved into a helper function (ext2_get_inode()), the rest
of ext2_{read,update}_inode() slightly cleaned up.

The patch below changes access_process_vm to use a new architecture
hook, flush_icache_user_range, instead of flush_icache_page, and adds
a definition of flush_icache_user_range which does the same thing as
flush_icache_page for all architectures except PPC.  (The PPC update
that is in Linus' BK tree already includes a suitable definition of
flush_icache_user_range.)

The reason for doing this is that when flush_icache_page is called
from do_no_page or do_swap_page, I want to be able to do the flush
conditionally, based on the state of the page.  In contrast,
access_process_vm needs to do the flush unconditionally since it has
just modified the page.  In the access_process_vm case it is useful to
have the information about the user address and length that have been
modified since then we can just flush the affected cache lines rather
than the whole page.

This patch should make it easy to improve performance on alpha, since
there (as I understand it) the icache flush is not needed at all in
do_no_page or do_swap_page, but is needed in access_process_vm.  All
that is needed is to make flush_icache_page a noop on alpha.  The
patch below doesn't do this, I'll let the alpha maintainers push that
change if they want.

This patch fixes a compile error on PPC.  It's in sd_find_target, a
function that returns a kdev_t.

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

This one-liner fixes an error case in Menuconfig when awk fails.
Written by Andrew Church (achurch@achurch.org).
Reviewed and tested by Michael Elizabeth Chastain (mec@shout.net).

Michael Elizabeth Chastain

===

fs/proc/inode.c is using __init, but for some reason missing an
#include <linux/init.h>. Add this.

Add Andi Kleen as x86-64 maintainer.

This adds the x86_64 arch and asm directories and a Documentation/x86_64.

It took a bit longer because I first had to make preemption and thread_info
work and also found some other bugs while doing this. The port has been
tested for a long time on UP.

I'm not sure what I should describe.  A lot is based on i386 with
a lot of cleanups. I wrote a paper about it for last year's OLS that describes
most of the changes (ftp://ftp.firstfloor.org/pub/ak/x86_64.ps.gz). It is
a bit outdated now, but should give a good overview.

It currently has a completely cut'n'pasted from others+hacked 32bit
emulation. I hope to clean that up in the future by merging the generic
core of this with other 64bit archs.

Thanks,
-Andi

Just an gcc 3.1 warning fix. It now warns about __FUNCTION__ string
concatenation. Also remove the check because it does not seem to trigger
ever.

-Andi

Add help texts for CONFIG_PCMCIA_AXNET and CONFIG_PCMCIA_XIRCOM

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

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

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

Integrate ALSA into v2.5.4

            Jaroslav

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

  condition, we test the preemption count in preempt_schedule(). This reduces the icache
  footprint and the overhead of preemption.

- plus optimize the irq-path preemption check a bit.

this is a fragile piece of the ptrace code, the code relies on a single wakeup coming from the parent.
This fix is necessery after the preempt_schedule() cleanups, it unbreaks 'strace strace ...'.

fixes a preemption race that was introduced by my removal of PREEMPT_ACTIVE.

into hostme.bitkeeper.com:/ua/repos/g/gkernel/net-drivers-2.5

into hostme.bitkeeper.com:/ua/repos/g/gkernel/misc-2.5

- the PREEMPT_ACTIVE trick is not needed

- schedule() should check for need_resched, we might miss a
  reschedule otherwise.

the cleanup also fixes the bug. The only reason why i kept
preempt_schedule() was to fix up p->state to TASK_RUNNING,
to make it possible to preempt from places that mark the
task TASK_UNINTERRUPTIBLE before adding the task to a waitqueue,
and thus a preemption in that small window could cause the
task to be removed from the runqueue erroneously.

  
this is a patch to prevent usb_set_interface() from erroneously resetting
the toggles for all endpoints instead of only the affected ones from the
requested interface/altsetting. I've also added some missing parentheses
to related macros in usb.h as I prefered not to take special care for
nasty side-effects ;-)
  
Patch below was created against 2.4.18-pre9 (with some lines of offset it
applies to 2.5.4-pre5 as well).
  
Tested in multi-interface configuration to provide evidence it:
* correctly identifies the affected endpoints and resets the toggles
* doesn't touch endpoints from other interfaces
* provides correct handling of shared EP0
* solves an issue I had with 2.4.18-pre9 where setting one interface
  occasionally caused transfers on other interface to hang due to lost
  toggle synchronisation

Despite being a pure bugfix, well localized and (IMHO) pretty obviously
correct wrt. USB-spec, I'd like to suggest including this in early
2.4.19-pre. Just in case some existing driver would somehow workaround
the currently wrong behavior and might break with this fix. And it's
not very urgent right now, as we are probably close to 2.4.18-rc1.
  
Regards,
Martin