Create "export_operations" interface for filesystems to describe
whether and how they should be exported.

- add new field in struct super_block "s_export_op" to describe
  how a filesystem is exported (i.e. how filehandles are mapped to
  dentries).
- New module: fs/exportfs for holding helper code for mapping between
  filehandles and dentries
- Change nfsd to use new interface if it exists.
- Change ext2 to provide new interface
- Add documention to filesystems/Exporting

If s_export_op isn't set, old mechanism still works, but it is
planned to remove old method and only use s_export_op.

Prepare for new export_operations interface (for filehandle lookup):

 - define d_splice_alias and d_alloc_anon.
 - define shrink_dcache_anon for removing anonymous dentries
 - modify d_move to work with anonymous dentries (IS_ROOT dentries)
 - modify d_find_alias to avoid anonymous dentries where possible
   as d_splice_alias and d_alloc_anon use this
 - put in place infrastructure for s_anon allocation and cleaning
 - replace a piece of code that is in nfsfh, reiserfs and fat
   with a call to d_alloc_anon
 - Rename DCACHE_NFSD_DISCONNECTED to DCACHE_DISCONNECTED
 - Add documentation at Documentation/filesystems/Exporting

Advansys SCSI driver update:
 - locking fixes
 - handle the "address" -> "page+offset" switch

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

A few (anal) comment cleanups and additions in relationship to the new
task cpu affinity syscalls.  All no brainers.

This fixes the mpparse.c clobbering the last ACPI patch did. Martin, look
OK? Again, my apologies.

This fixes a race in migration_thread which results in a deadlock on
boot for some SMP systems.  The fix is to to disable preemption inside
of set_cpus_allowed.

Andrew Morton first noticed the problem and provided the following patch
a few weeks back.  I was not affected until the recent migration_init
fix, for some odd reason.  Neither Andrew nor I think this is actually
kernel preemption's fault but perhaps a race in the tricky behavior of
the migration code.

This patch is the start of the cleanup of the fbdev layer. It has been
approved by Geert and has been tested for some time in the Dave Jones
tree.

Remove localy defined wait queues and use wait queues
in tty structure of same function. This matches the
n_tty.c behavior.

Handle pty hangup when blocked on read.

These 2 changes fix use of n_hdlc with PPPoATM and
are mirror changes included in 2.4.19-pre

patch to update virt_to_bus functions and remove version depedent #ifdef
statements

This is originally from Andrew in the 2.4 series, please apply for 2.5
as well.

Fix oops in st_open..

We've seen this in several other drivers, most recently the indydog one.
  If two simultaneous opens occur, they race, they device gets opened
twice, blah, blah, blah.  Using atomic bitops fixes this.  The BKL is
not needed.

This patch adds #include <linux/threads.h> to include/linux/smp.h,
because it (smp.h) needs the definition of NR_CPUS.  (It so happens
that include/asm-i386/smp.h includes <linux/threads.h>, but IMHO
include/linux/smp.h shouldn't rely on that).

This is needed to for 2.5.7 FAT to build on ARM.

Include fixes to allow ALSA to compile.

On the swap_out() path, the radix-tree pagecache is allocating its
nodes with PF_MEMALLOC set, which allows it to completely exhaust the
free page lists(*).  This is fairly easy to trigger with swap-intensive
loads.

It would be better to make those node allocations fail at an earlier
time.  When this happens, the radix-tree can still obtain nodes from its
mempool, and we leave some memory available for the I/O layer.
(Assuming that the I/O is being performed under PF_MEMALLOC, which it
is).

So the patch simply drops PF_MEMALLOC while adding nodes to the
swapcache's tree.

We're still performing atomic allocations, so the rat is still biting
pretty deeply into the page reserves - under heavy load the amount of
free memory is less than half of what it was pre-rat.

It is unfortunate that the page allocator overloads !__GFP_WAIT to also
mean "try harder".  It would be better to separate these concepts, and
to allow the radix-tree code (at least) to perform atomic allocations,
but to not go below pages_min.  It seems that __GFP_TRY_HARDER will be
pretty straightforward to implement.  Later.

The patch also impements a workaround for the mempool list_head
problem, until that is sorted out.



(*) The usual result is that the SCSI layer dies at scsi_merge.c:82.
It would be nice to have a fix for that - it's going BUG if 1-order
allocations fail at interrupt time.  That happens pretty easily.

I've recently (actually, last month, but I had been a bit too busy
since then) come across a wee problem, in what I originally thought
was the VFAT code -- having `utf8' as one of the options, creating
UTF-8 file names on a VFAT partition mysteriously gains a couple of
(random) characters just after the UTF-8 escaped character: eg.
touch "fooCbar" where C is an UTF-8 escape sequence ends up creating
a file named "fooCRbar". (R being some random character.)

I eventually tracked it down to one line in fs/nls/nls_base.c -- the
UCS-2 (wchar_t) string pointer was being incremented too fast. After
consulting Ogawa Hirofumi-san on the subject, he mentioned that
include/linux/nls.h also needs to be changed for proper UTF-8
support in the NLS code.

Originally from Brian Gerst

(Includes the bfs fix sent prior to this one to this -- disregard
 earlier bfs related email)

Missed a page->buffers -> page->private conversion.
Apologies..

This patch adds 5 help texts to arch/ia64/Config.help.  The texts were
obtained from Eric S.  Raymond's v2.97 Configure.help.

The patch to the PnP BIOS driver that was in 2.5.7-dj and which
went into 2.5.8-pre1 did not include Brian Gerst's SMP fix.

 - fixe compile error (scatterlist::address replaced)
 - simplify obtaining ram disk memory (using vmalloc)
 - improve SCSI INQUIRY and MODE SENSE support

 - allow detection of pre-existing disk geometry

- Updated fs/devfs/util.c to fix shift warning on 64 bit machines
  Thanks to Anton Blanchard <anton@samba.org>

- Updated README from master HTML file

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

- Expand configure help options a bit
- Fix xconfig bug
- Decrease queue depth if a command takes too long to complete
- Test master/slave stuff. It works, but one device can heavily starve
   another. This is the simple approach right now, means that one device
   will wait until the other is completely idle before starting any
   commands This is not necessary since we can have queued commands on
   both devices at the same time. TODO.
- Add proc output for oldest command, just for testing.
- pci_dev compile fixes.
- Make sure ide-disk doesn't BUG if TCQ is not used, basically this was
   fixed by off-loading the using_tcq setting to ide-tcq.
- Remove warning about 'queued feature set not supported'
- Abstract ide_tcq_wait_dataphase() into a function

- Synchronize with 2.5.8.

- Eliminate the cdrom_log_sense() function.

- Pass a struct request to cdrom_analyze_sense_data() since this is the entity
   this function is working on. This shows nicely that this function is broken.

- Use CDROM_PACKET_SIZE where appropriate.

- Kill the obfuscating cmd_buf and cmd_len local variables from
   cdrom_transfer_packet_command(). This made it obvious that the parameters of
   this function where not adequate - to say the least. Fix this.

- Pass a packed command array directly to cdrom_queue_packed_command().  This
   is reducing the number of places where we have to deal with the c member of
   struct packet_command.

- Never pass NULL as sense to cdrom_lockdoor().

- Eliminate cdrom_do_block_pc().

- Eliminate the c member of struct packet_command. Pass them through struct
   request cmd member.

- Don't enable TCQ unconditionally if there is a TCQ queue depth defined.

- Fix small think in ide_cmd_ioctl() rewrite. (My appologies to everyone who
   has to use hdparm to setup his system...)

- Fix compilation without PCI support.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

- irq handlers should be cache-affine to a large degree, without the
  explicit use of /proc/irq/*/smp_affinity.

- idle CPUs should be preferred over busy CPUs when directing IRQs towards
  them.

- the distribution of IRQs should be random, to avoid all IRQs going to
  the same CPU, and to avoid 'heavy' IRQs from loading certain CPUs
  unfairly over CPUs that handle 'light' IRQs. The IRQ system has no
  knowledge about how 'heavy' an IRQ handler is in terms of CPU cycles.

here is the design and implementation:

- we make per-irq decisions about where the IRQ will go to next. Right
  now it's a fastpath and a slowpath, the real stuff happens in the slow
  path. The fastpath is very lightweight.

- [ i decided not to measure IRQ handler overhead via RDTSC - it ends up
    being very messy, and if we want to be 100% fair then we also need to
    measure softirq overhead, and since there is no 1:1 relationship
    between softirq load and hardirq load, it's impossible to do
    correctly. So the IRQ balancer achieves fairness via randomness. ]

- we stay affine in the micro timescale, and we are loading the CPUs
  fairly in the macro timescale. The IO-APIC's lowest priority
  distribution method rotated IRQs between CPUs once per IRQ, which was
  the worst possible solution for good cache-affinity.

- to achieve fairness and to avoid lock-step situations some real
  randomness is needed. The IRQs will wander in the allowed CPU group
  randomly, in a brownean motion fashion. This is what the 'move()'
  function accomplishes. The IRQ moves one step forward or one step
  backwards in the allowed CPU mask. [ Note that this achieves a level of
  NUMA affinity as well, nearby CPUs are more likely to be NUMA-affine. ]

- the irq balancer has some knowledge about 'how idle' a single CPU is.
  The idle task updates the idle_timestamp. Since this update is in the
  idle-to-be codepath, it does not increase the latency of idle-wakeup,
  the overhead should be zero in all cases that matter. The idle-balancing
  happens the following way: when searching for the next target CPU after
  a 'IRQ tick' has expired, we first search 'idle enough' CPUs in the
  allowed set. If this does not succeed then we search all CPUs.

- the patch is fully compatible with the /proc/irq/*/smp_affinity
  interface as well, everything works as expected.

note that the current implementation can be expressed equivalently in
terms of timer-interrupt-driven IRQ redirection. But i wanted to get some
real feedback before removing the possibility to do finer grained
decisions - and the per-IRQ overhead is very small anyway.

into wailua.hpl.hp.com:/bk/lia64/to-linus-2.5

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

fixes this problem.

into flint.arm.linux.org.uk:/usr/src/linux-bk-2.5/linux-2.5-rmk

into flint.arm.linux.org.uk:/usr/src/linux-bk-2.5/linux-2.5-rmk

This patch updates the defconfig for the Shark and adds an
extern and a define so that the kernel compiles for the Shark.

Regards
  Alexander

Make arch/arm/kernel/armksyms.c compile again with gcc 3.0.2 because of new EXPORT_SYMBOL_NOVERS(abort); in patch-2_4_18-rmk3.gz. See my mail "EXPORT_SYMBOL_NOVERS(abort) in armksyms.c?" in linux-arm-kernel list from Mon, 25 Mar 2002.

Dirk

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