[PATCH] Add char_devs to st
This patch adds support for cdevs to the st driver. The changes are based on
Doug Gilbert's corresponding changes to the sg driver. Using cdevs brings the
following advantanges:
- support for many drives, currently the maximum is set to 128; the minor
  number assignment is explained in the patch to Documentation/scsi/README.st
- the tape devices appear in /sys/cdev/major/st*, as an example here are
  the entries for the first drive (4 modes, rewind and non-rewind
  devices):
  /sys/cdev/major/st0m0   /sys/cdev/major/st0m1   /sys/cdev/major/st0m2
  /sys/cdev/major/st0m3
  /sys/cdev/major/st0m0n  /sys/cdev/major/st0m1n  /sys/cdev/major/st0m2n
  /sys/cdev/major/st0m3n

Merge raven.il.steeleye.com:/home/jejb/BK/scsi-tmp-2.7
into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.6

[SPARC32]: Fix build after show_interrupts() changes.

[SPARC64]: Fix build after show_interrupts() changes.

Merge nuts.ninka.net:/disk1/davem/BK/sparcwork-2.6
into nuts.ninka.net:/disk1/davem/BK/sparc-2.6

Merge bk://gkernel.bkbits.net/net-drivers-2.5
into home.osdl.org:/home/torvalds/v2.5/linux

[netdrvr e100] remove __devinit markers, fixing oops

[netdrvr 8139too] Don't hold the lock across pci_set_power_state() - it can sleep

[netdrvr sis900] add suspend/resume support

The attached patch adds support for suspend/resume to the sis900 driver.
With this patch on resume the NIC is fully configured and operational,
before a module reload was needed because of the complete lack of
suspend/resume callbacks.

I added two functions, sis900_suspend and sis900_resume, with their
pointers in struct pci_driver. A vector of 16 u32 was then needed to the
to keep PCI data during suspend. I added it in struct sis900_private.
I updated the revision number to reflect my changes.
Looking at the code I also killed three typos.

The patch doesn't touch any other code.

Since I don't know anything on ethernet drivers the rule 'works for me'
is fully valid.

Merge ia64 conflicts

Merge bk://bk.arm.linux.org.uk/linux-2.6-serial
into home.osdl.org:/home/torvalds/v2.5/linux

Merge bk://kernel.bkbits.net/davem/net-2.6
into home.osdl.org:/home/torvalds/v2.5/linux

[PATCH] dm: dm_table_event() sleep on spinlock bug

From: Joe Thornber <thornber@sistina.com>

You can no longer call dm_table_event() from interrupt context.

[PATCH] dm: set io restriction defaults

From: Joe Thornber <thornber@sistina.com>

Make sure that a target has a sensible set of default io restrictions.

[PATCH] dm: make v4 of the ioctl interface the default

From: Joe Thornber <thornber@sistina.com>

Make the version-4 ioctl interface the default kernel configuration option.
If you have out of date tools you will need to use the v1 interface.

[PATCH] dm: remove dynamic table resizing

From: Joe Thornber <thornber@sistina.com>

The dm table size is always known in advance, so we can specify it in
dm_table_create(), rather than relying on dynamic resizing.

[PATCH] dm: fix block device resizing

From: Joe Thornber <thornber@sistina.com>

When setting the size of a Device-Mapper device in the gendisk entry, also
try to set the size of the corresponding block_device entry's inode.  This is
necessary to allow online device/filesystem resizing to work correctly.
[Kevin Corry]

[PATCH] name_to_dev_t() fix

From: viro@parcelfarce.linux.theplanet.co.uk

When we register disks, we mangle the disk names that contain slashes (e.g.
cciss/c0d0) replacing them with '!' in corresponding sysfs names.  So
name_to_dev_t() should mangle the name in the same way before looking for it
in /sys/block.

[PATCH] Kernel Locking Documentation update

From: Rusty Russell <rusty@rustcorp.com.au>

Entirely revised, and largely rewritten.  Has a continuing example now, which
I think makes things clearer.  Also covers Read Copy Update.  This version
further deprecates rwlock_t, shuffles sections for better organization.

[PATCH] VIA audio fixes

From: Alan Cox <alan@redhat.com>

VIA audio had a fix from 2.4 missing so any user could spam the system log. Also
include a fix for a bug which is pending 2.4 fixing too and causes a bogus
warning to be displayed on close of audio file handle.

[PATCH] cycx_drv warning fix

From: Alan Cox <alan@redhat.com>

Type errors, just fixes a warning

[PATCH] SCC warning fix

From: Alan Cox <alan@redhat.com>

Just a warning fix and behaviour tidy. Changing the kiss.mintime variable isn't
going to work as its exposed to user space

[PATCH] update sn2 MAINTAINERS file entry

From: jbarnes@sgi.com (Jesse Barnes)

Just a quick patch to fix MAINTAINERS for sn2.

[PATCH] Winbond w83627hf driver

From: Pádraig Brady <P@draigBrady.com>

Watchdog driver for the Winbond w83627hf which is on the last 3 motherboards
I got here for test (tyan, advantech, force).

[PATCH] Fix ioctl related warnings in userspace

From: Johannes Stezenbach <js@convergence.de>

the patch below removes warnings like:

  warning: signed and unsigned type in conditional expression

when compiling userspace applications against a glibc built with 2.6 kernel
headers (like on Debian unstable).

[PATCH] Rename legacy_bus to platform_bus

From: Jeff Garzik <jgarzik@pobox.com>

I've seen this patch floating around.  Not sure the origin, but it's
surfaced on lkml and also when I was poking around handhelds.org CVS for
iPAQ patches:  on non-PCs, particularly system-on-chip devices but not
just there, you have a custom "platform bus" that is the root of pretty
much all other devices and buses.

It's something I wanted to make sure people didn't forget; to make sure
the legacy_bus didn't get "legacied out of existence."  ;-)

[PATCH] synchronize use of mm->core_waiters

From: Roland McGrath <roland@redhat.com>

I believe I have identified a failure mode that Linus saw a couple weeks
back when tracking down some other fork/exit sorts of races.  We saw this
come up on rare occasions with the RHEL3 kernel's backport of the new code
(while trying to track down other race failure modes we have yet to fix, sigh).

I am talking about the following scenario:

> Btw, even with the fix, doing a "while : ; ./crash t 10 ; done" will
> eventually result in a stuck process:
>
>   1415 tty1     D      0:00 ./crash
>
> This is some kind of deadlock: most of the fifty threads are in "D"
> state, with a trace something like
>
>   [<c011fbe3>] schedule+0x360/0x7f8
>   [<c0120539>] wait_for_completion+0xd4/0x1c3
>   [<c0128c9e>] do_exit+0x627/0x6a4
>   [<c0128ddd>] do_group_exit+0x3d/0x177
>   [<c0130c13>] dequeue_signal+0x2d/0x84
>   [<c0133911>] get_signal_to_deliver+0x390/0x575
>   [<c010a541>] do_signal+0x6c/0xf1
>   [<c01200be>] default_wake_function+0x0/0x12
>   [<c01200be>] default_wake_function+0x0/0x12
>   [<c013d50f>] do_futex+0x6d/0x7d
>   [<c013d635>] sys_futex+0x116/0x12f
>   [<c010a601>] do_notify_resume+0x3b/0x3d
>   [<c010a82e>] work_notifysig+0x13/0x15
>
> except for one that is trying to core-dump:
>
>   [<c0120539>] wait_for_completion+0xd4/0x1c3
>   [<c01200be>] default_wake_function+0x0/0x12
>   [<c01200be>] default_wake_function+0x0/0x12
>   [<c02101aa>] rwsem_wake+0x86/0x12d
>   [<c01738af>] coredump_wait+0xa8/0xaa
>   [<c0173a26>] do_coredump+0x175/0x26c
>
> and three that are just doing a regular "exit()" system call:
>
>   [<c011fbe3>] schedule+0x360/0x7f8
>   [<c011e19a>] recalc_task_prio+0x90/0x1aa
>   [<c0120539>] wait_for_completion+0xd4/0x1c3
>   [<c01200be>] default_wake_function+0x0/0x12
>   [<c01200be>] default_wake_function+0x0/0x12
>   [<c0210207>] rwsem_wake+0xe3/0x12d
>   [<c0128c9e>] do_exit+0x627/0x6a4
>   [<c0128d4d>] next_thread+0x0/0x53
>   [<c010a7e3>] syscall_call+0x7/0xb
>
> However, the rest of the system is totally unaffected by this deadlock:
> it's only deadlocked withing the thread group itself, nobody else cares.

What happens here is a race between an exiting thread checking
mm->core_waiters in __exit_mm, and the thread taking the core-dump signal
(in coredump_wait) examining the first thread's ->mm pointer and
incrementing mm->core_waiters to account for it.  There is no
synchronization at all in __exit_mm's use of mm->core_waiters.  If the
coredump_wait thread reads tsk->mm when tsk is in __exit_mm between
checking mm->core_waiters and clearing tsk->mm, then it will increment
mm->core_waiters and the total count will later exceed the number of
threads that will ever decrement it and synchronize.  Hence it blocks forever.

The following patch fixes the problem by using mm->mmap_sem in __exit_mm.
The read lock must be held around checking mm->core_waiters and clearing
tsk->mm so that coredump_wait (which gets the write lock) cannot come in
between and do bogus bookkeeping.

[PATCH] DAC960 request queue per disk

From: Dave Olien <dmo@osdl.org>

Here's a patch that changes the DAC960 driver from having one request
queue for ALL disks on the controller, to having a request queue for
each logical disk.  This turns out to make little difference for deadline
scheduler, nor for AS scheduler under light IO load.  But under AS
scheduler with heavy IO, it makes about a 40% difference on dbt2
workload.  Here are the measured numbers:

The 2.6.0-test11-D kernel version includes this mutli-queue patch to the
DAC960 driver.

For non-cached dbt2 workload  (heavy IO load)

Scheduler kernel/driver NOTPM(bigger is better)
AS 2.6.0-test11-D  1598
AS 2.6.0-test11     973
deadline 2.6.0-test11    1640
deadline 2.6.0-test11-D  1645

For cached dbt2 workload (lighter IO load)

AS 2.6.0-test11-D  4993
AS 2.6.-test6-mm4  4976, 4890, 4972
deadline 2.6.0-test11-D  4998

Can this be included in 2.6.0?  I know it's not a "critical patch"
in the sense that something won't work without it.  On the other hand,
the change is isolated to a driver.

[PATCH] fix userspace compiles with nbd.h

From: Paul Clements <Paul.Clements@SteelEye.com>

A previous "cleanup" on the nbd.h header file broke userspace compiles.
I've added an #ifdef __KERNEL__ so that userspace doesn't need to worry
about the nbd_device structure, which is only used in-kernel. The patch
allows me to compile my nbd tools with the 2.6 nbd.h.

[PATCH] isdn_ppp_ccp.c uses uninitialized spinlock

From: Tonnerre Anklin <thunder@keepsake.ch>

This spinlock was used uninitialized. Gave me a lot of warnings.

[PATCH] nr_slab accounting fix

From: Manfred Spraul <manfred@colorfullife.com>

if alloc_slabmgmt fails, then kmem_freepages() calls sub_page_state(),
altough nr_slab was not yet increased.  The attached patch fixes that by
moving the inc_page_state into kmem_getpages().

[PATCH] More MODULE_ALIASes

From: Rusty Russell <rusty@rustcorp.com.au>
      Steve Youngs, Stephen Hemminger

Three more MODULE_ALIASes.  Trivial, but useful if people want things
to "just work" in 2.6.0.

[PATCH] struct_cpy compilation warning

From: Ingo Molnar <mingo@elte.hu>

i've attached a minor fix for the 2.6.1 timeframe - we clearly meant
__struct_cpy_bug().  Newest versions of gcc warn about this.

[PATCH] slab reclaim accounting fix

From: Manfred Spraul <manfred@colorfullife.com>

slab_reclaim_pages is increased even if get_free_pages fails.  The attached
patch moves the update to the correct position.

[PATCH] fix outdated comment in jiffies.h

From: Tim Schmielau <tim@physik3.uni-rostock.de>

[PATCH] Allow unimap change on non fg console

From: Kurt Garloff <garloff@suse.de>

The comment in front of vt_ioctl() reads
/*
 * We handle the console-specific ioctl's here.  We allow the
 * capability to modify any console, not just the fg_console.=20
 */

Unfortunately, this does not apply to PIO_UNIMAPCLR, nor
GIO_/PIO_UNIMAP. They always operate on the current foreground
console, which is inconsistent at least. For most ioctls, the
comment is applicable.

It also causes problems, as setfont can't do the full job on
the non-fg consoles. (OK, our setfont is slightly changed to
even try it ... as you know.)

The attached patch does fix this.

I have a similar patch for 2.4, but it never got merged :-(
because not many people seem to care and I submitted in the middle
of the 2.4 series ...
It has been in UnitedLinux/SUSE kernels for ages, though.

[PATCH] Clear dirty bits etc on compound frees

From: "Martin J. Bligh" <mbligh@aracnet.com>,
      Guillaume Morin <guillaume@morinfr.org>

We need to clear the software dirty bit on the tail pages of a compound page
when freeing it up.

The tail pages can become dirtied by mmap'ing /dev/mem, and writing into
any clustered page group (that a driver might have created or whatever).

Plus it's better to run all these pages through the free_pages_check checks
anyway.

[PATCH] list_empty_careful() documentation.

From: Ingo Molnar <mingo@elte.hu>

I'd also suggest the following patch below, to clarify the use of
unsynchronized list_empty().  list_empty_careful() can only be safe in the
very specific case of "one-shot" list entries which might be removed by
another CPU.  (but nothing else can happen to them and this is their only
final state.) list_empty_careful() is otherwise completely unsynchronized
on both the compiler and CPU level and is not 'SMP safe' in any way.

[PATCH] MAINTAINERS vger.rutgers.edu

From: Geert Uytterhoeven <geert@linux-m68k.org>

Mailing lists at vger.rutgers.edu are obsolete, use vger.kernel.org
instead.

[PATCH] more correct get_compat_timespec interface

From: Joe Korty <joe.korty@ccur.com>

The API for get_compat_timespec / put_compat_timespec is incorrect, it
forces a caller with const args to (incorrectly) cast.  The posix message
queue patch is one such caller.

[PATCH] dvb i2c timeout fix

From: Gerd Knorr <kraxel@bytesex.org>

Below is a ObviouslyCorrect[tm] patch which fixes the i2c bus timeout
handling in the saa7146 driver.

[PATCH] JBD: b_committed_data locking fix

The locking rules say that b_committed_data is covered by
jbd_lock_bh_state(), so implement that during the start of commit, while
throwing away unused shadow buffers.

I don't expect that there is really a race here, but them's the rules.

[PATCH] O_DIRECT memory leak fix

From: Badari Pulavarty <pbadari@us.ibm.com>

I found the problem with O_DIRECT memory leak.

The problem is, when we are doing DIO read and crossed the end of file - we
don't release referencess on all the pages we got from get_user_pages().
(since it is a success case).

The fix is to call dio_cleanup() even for sucess cases.

[PATCH] fix ELF exec with huge bss

From: Roland McGrath <roland@redhat.com>

The following test program will crash every time if dynamically linked.
I think this bites all 32-bit platforms, including 32-bit executables on
64-bit platforms that support them (and could in theory bite 64-bit
platforms with bss sizes beyond the bounds of comprehension).

volatile char hugebss[1080000000];
main() { printf("%p..%p\n", &hugebss[0], &hugebss[sizeof hugebss]);
 system("cat /proc/$PPID/maps");
 hugebss[sizeof hugebss - 1] = 1;
 return 23;
}

The problem is that the kernel maps ld.so at 0x40000000 or some such place,
before it maps the bss.  Here the bss is so large that it overlaps and
clobbers that mapping.  I've changed it to map the bss before it loads the
interpreter, so that part of the address space is reserved before ld.so's
mapping (which doesn't really care where it goes) is done.

This patch also adds error checking to the bss setup (and interpreter's bss
setup).  With the aforementioned change but no error checking, "ulimit -v
65536; ./hugebss" will crash in the store after the `system' call, because
the kernel will have failed to allocate the bss and ignored the error, so
the program runs without those pages being mapped at all.  With this change
it dies with a SIGKILL as for a failure to set up stack pages.  It might be
even better to try to detect the case earlier so that execve can return an
error before it has wiped out the address space.  But that seems like it
would always be fragile and miss some corner cases, so I did not try to add
such complexity.

[PATCH] Erronous use of tick_usec in do_gettimeofday

From: Joe Korty <joe.korty@ccur.com>

do_gettimeofday() is using tick_usec which is defined in terms of USER_HZ
not HZ.

[PATCH] md: set ra_pages for raid0/raid5 devices properly.

From: NeilBrown <neilb@cse.unsw.edu.au>

stripe to be effective.  This patch sets ra_pages
appropriately.

[PATCH] md: Limit max_sectors on md when merge_bvec_fn defined on underlying device.

From: NeilBrown <neilb@cse.unsw.edu.au>

As no md personalities honour the merge_bvec_fn of underlying devices,
we must make sure never to submit a bio larger than 1 page when a
merge_bvec_fn is defined.

raid5 already does this (it never submits bios larger than one page).
With this patch, all other raid personalities limit their
max_sectors when a merge_bvec_fn is present.

[PATCH] BINFMT_ELF=m is not an option

From: glee@gnupilgrims.org

I think Adrian had forgotten to update the help text.

[PATCH] Ext3+quota deadlock fix

From: Jan Kara <jack@ucw.cz>

here's patch which should fix deadlock with quotas+ext3 reported in 2.4
(the same problem existed in 2.6 but nobody found it).

[PATCH] Fix possible oops in vfs_quota_sync()

From: Jan Kara <jack@ucw.cz>

I'm sending you a fix of possible Oops in vfs_quota_sync().  Actually
nobody has run into that I found it when I was looking through the code.

[PATCH] sis comparison / assignment operator fix

From: Geoffrey Lee <glee@gnupilgrims.org>

This fixes what seems to be an obvious = vs == bug in the init301.c sis
file.

[PATCH] remove mm->swap_address

From: William Lee Irwin III <wli@holomorphy.com>

This field is 100% unused. This patch removes it.

[PATCH] Fix 32bit siginfo problems on x86-64

From: Andi Kleen <ak@muc.de>

32bit siginfo would sometimes get passed incorrectly on x86-64. This
change fixes the conversion function to be a bit dumber, but more
correct.

[PATCH] Don't panic in mpparse on x86-64

From: Andi Kleen <ak@muc.de>

Merge i386 fix. Don't panic in MP table parsing when the table is bad.

[PATCH] Signal fixes for x86-64

From: Andi Kleen <ak@muc.de>

Merge signal race fixes from i386 to x86-64.

Fix a bug in system call restart, noted by John Blackwood.

[PATCH] Merge i386 fix for page fault to x86-64

From: Andi Kleen <ak@muc.de>

Merge the i386 fix for the page fault from Linus to x86-64
(I'm not actually sure what it fixes, but if it's good for 32bit
it is likely good for 64bit too)

[PATCH] Add more paranoid checking in x86-64 prefetch checker

From: Andi Kleen <ak@muc.de>

Make sure we never access anything in kernel mapping while
doing the prefetch workaround checks on x86-64.

Originally suggested by Jamie Lockier.

[PATCH] Fix 32bit truncate on x86-64

From: Andi Kleen <ak@muc.de>

Another potential data corruption fix.

The 32bit truncate64 on x86-64 did silently truncate
offsets >32bit. That broke mysql for example. Fix that.

From Chris Wilson

[PATCH] Fix sysrq-t on x86-64

From: Andi Kleen <ak@muc.de>

From Badari Pulavarty

Without this sysrq-t shows the same backtrace for all processes on x86-64

[PATCH] Fix CPUID compilation on x86-64

From: Andi Kleen <ak@muc.de>

A lot of people have run into this: the x86-64 cpuid driver didn't
compile as module.

Using a kludge suggested by Sam Ravnsborg.

[PATCH] Critical x86-64 IOMMU fixes for 2.6.0

From: Andi Kleen <ak@muc.de>

Please consider applying this patch, I would consider it critical for x86-64.

The 2.6.0 x86-64 IOMMU code unfortunately had a few problems, leading
to non booting systems and in a few cases to data corruption.

It fixes a two serious bugs in handling special kinds of scatter gather
lists in pci_map_sg.

AGP was completely broken with IOMMU because of a wrong #ifdef.
Fix that.

One TLB flush optimization I did a long time ago seems to break on
some 3ware boards (who require IOMMU because they don't support 64bit
addresses).  The breakage lead to data corruption. This patch diables
the optimization for now and fixes a potential SMP race in the flush
code too. The TLB flush is done in a slower, but more reliable way
now too.

This patch fixes them. Please consider applying, because some of these
problems hit quite many people.

This also disables the IOMMU_DEBUG in the defconfig. A lot of people
were using the IOMMU when they didn't need to, which multiplied the
problems.

IOMMU merge is disabled for now. This was an experimental optimization
which helped with some block devices, but for production it seems to
be better to disable it for now because there are some questionable
corner cases when the IOMMU aperture fragments. The same is done
for IOMMU SAC force, which was related to that.

i386 has quite broken semantics for pci_alloc_consistent(). It uses
the standard device DMA mask instead of the consistent mask. Make us
bug-to-bug compatible here. This fixes problems with some sound
drivers that don't support full 32bit addressing.

[PATCH] Add a.out support for x86-64

From: Andi Kleen <ak@muc.de>

Add 32bit a.out support for x86-64.

Not exactly an important bug fix, but maybe it will help someone.  This
should increase the current 98% compatibility to i386 to perhaps 98.1% @)

I tested an old a.out SuSE 4.2 installation in chroot and it worked.  It
also ran some very old linux binaries from '92 found on ftp.funet.fi.  The
only program that didn't was the SuSE a.out GNU emacs, but I was too lazy
to track that down.  Core dumps are not supported.

[PATCH] statfs64 fix

From: Andi Kleen <ak@muc.de>

It fixes the statfs64 emulation on x86-64.  The problem is that x86-64
needs an __attribute__((aligned)) on the compat_statfs64 structure.  The
conclusion last time this was discussed was that the structure should be
duplicated.

Essentially it is the old shared structure copied to every user and x86-64
uses __attribute__((packed)).

[PATCH] dm and bounce buffer panic fix

From: Mark Haverkamp <markh@osdl.org>

About three weeks ago markw at osdl posted a mail about a panic that he
was seeing:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106737176716474&w=2

I believe what is happening, is that the dm __clone_and_map function is
generating bio structures with the bi_idx field non-zero.  When
__blk_queue_bounce creates a new bio with bounce pages, it sets the bi_idx
field to 0 rather than the bi_idx of the original.  This causes trouble since
bv_page pointers will be dereferenced later that are zero.  The following
uses the original bio structure's bi_idx in the new bio structure and in
copy_to_high_bio_irq and bounce_end_io.

This has cleared up the panic when using the volume.

(acked by Joe Thornber)

[PATCH] ext3: bd_claim for journal device

From: Neil Brown <neilb@cse.unsw.edu.au>

Change ext3 to run bd_claim() against external journal devices. It is
significant only for those who have ext3 journals on a separate device, and
gets exclusive access to that device.

[PATCH] remove include recursion from linux/pagemap.h

From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>

pagemap.h, do not include thyself.

[PATCH] remove lock_kernel() from proc_bus_pci_lseek()

Remove pointless lock_kernel(), replace with the standard-but-still-odd
i_sem-based lseek locking.

[PATCH] fix oops in proc_kill_inodes()

proc_kill_inodes() walks the s_files list, playing with ->f_dentry.

But there is a window in which __fput() will leave a file on that list with a
null f_dentry and f_vfsmnt.

I'm not sure it was ever confirmed that this fixed the reported oops, but it
seems much better to set those fields to null _after_ removing the filp from
the list.

(Actually, there's no need to null those pointers out at all.  But whatever;
it caught a bug).

[PATCH] pagefault accounting fix

From: William Lee Irwin III <wli@holomorphy.com>

Our accounting of minor faults versus major faults is currently quite wrong.

To fix it up we need to propagate the actual fault type back to the
higher-level code.  Repurpose the currently-unused third arg to ->nopage
for this.

[PATCH] Remove CLONE_FILES from init kernel thread creation

From: James Morris <jmorris@redhat.com>

The patch below removes the CLONE_FILES flag from the kernel_thread() call
which starts init.

This is to prevent other kernel threads from sharing file descriptors
opened by init (try 'lsof /dev/initctl' on a 2.6 system :-).

The reason this patch is being proposed is so that usermode helper apps
launched via kernel threads (e.g. modprobe, hotplug) do not then inherit
any such file descriptors.  This is not a problem in itself so far (other
than being messy), but it is a problem for SELinux, which will otherwise
need to grant access to /dev/initctl by modprobe and hotplug, a somewhat
undesirable scenario.

As far as I can tell, there is no reason why init needs to be spawned with
CLONE_FILES.  Please let me know if there are any objections to the
change, which I would like to propose for 2.6.0+ as a cleanup.

[PATCH] Add support for SGI's IOC4 chipset

From: Aniket Malatpure <aniket@sgi.com>

Adds support for the IOC4 IDE part.

[PATCH] new /proc/irq cpumask format; consolidate cpumask display and input code

From: Paul Jackson <pj@sgi.com>

This patch is a followup to one from Bill Irwin.  On Nov
17, he had consolidated the half-dozen chunks of code
that displayed cpumasks in /proc/irq/prof_cpu_mask and
/proc/irq/<pid>/smp_affinity into a single routine, which he
called format_cpumask().

I believe that Andrew Morton has accepted Bill's patch into
his 2.6.0-test10-mm1 patch set as the "format_cpumask" patch.
I hope that the following patch will replace Bill's patch.
I look forward to Bill's feedback on this patch.

The following patch carries Bill's work further:

 1) It also consolidates the input side (write syscalls).
 2) It adapts a new format, same on input and output.
 3) The core routines work for any multi-word bitmask,
    not just cpumasks.
 4) The core routines avoid overrunning their output
    buffers.

Note esp. for David Mosberger:

    The small patch I sent you and the linux-ia64 list
    yesterday entitled: "check user access ok writing
    /proc/irq/<pid>/smp_affinity" for arch ia64 only is
    _separate_ from the following patch.  Neither presumes the
    other.  However, they do collide on one line.  Last one in
    is a Monkey's Uncle and will need an updated patch from me
    (or otherwise need to resolve the one obvious collision).

Details of the following patch:

Both the display and input of cpumasks on 9 arch's are
consolidated into a single pair of routines, which use the
same format for input and output, as recommended by Tony
Luck.  The two common routines work on any multi-word bitmask
(array of unsigned longs).  A pair of trivial inline wrappers
cpumask_snprintf() and cpumask_parse() hide this generality
for the common case of cpumask input and output.

My real motivation for consolidating this code will become
visible later - when I seek to add a nodemask_t that resembles
cpumask_t (just a different length).  These common underlying
routines will be used there as well, following up on a suggestion
of Christoph Hellwig that I investigate implementing nodemask_t
as an ADT sharing infrastructure with cpumask_t.  However, I
believe that this patch stands on its own merit, consolidating
a couple hundred lines of duplicated code, and making the
cpumask display format usable on very large systems.

There are two exceptions to the consolidation - the alpha and
sparc64 arch's manipulate bare unsigned longs, not cpumask_t's,
on input (write syscall), and do stuff that was more funky than
I could make sense of.  So the input side of these two arch's
was left as-is.  I'd welcome someone with access to either of
these systems to provide additional patches.

The new format consists of multiple 32 bit words, separated by
commas, displayed and input in hex.  The following comment from
this patch describes this format further:

* The ascii representation of multi-word bit masks displays each
* 32bit word in hex (not zero filled), and for masks longer than
* one word, uses a comma separator between words.  Words are
* displayed in big-endian order most significant first.  And hex
* digits within a word are also in big-endian order, of course.
*
* Examples:
*   A mask with just bit 0 set displays as "1".
*   A mask with just bit 127 set displays as "80000000,0,0,0".
*   A mask with just bit 64 set displays as "1,0,0".
*   A mask with bits 0, 1, 2, 4, 8, 16, 32 and 64 set displays
*     as "1,1,10117".  The first "1" is for bit 64, the second
*     for bit 32, the third for bit 16, and so forth, to the
*     "7", which is for bits 2, 1 and 0.
*   A mask with bits 32 through 39 set displays as "ff,0".

The essential reason for adding the comma breaks was to make
the long masks from our (SGI's) big 512 CPU systems parsable by
humans.  An unbroken string of 128 hex digits is pretty difficult
to read.  For those who are compiling systems with CONFIG_NR_CPUS
of 32 or less, there should be no visible change in format.

There are of course a thousand possible output formats that
meet similar criteria.  If someone wants to lobby for and seek
consensus behind another such format, that's fine.  Now that
the format is consolidated into a single pair of routines,
it should be easy to adapt whatever we choose.

Internally, the display routine uses snprintf to track the
remaining space in its output buffer, to avoid the risk of
overrunning it.

A new file, lib/mask.c, is added to the lib directory, to
hold the two common routines.  I anticipate adding a few more
common routines for generic support of multi-word bit masks to
lib/mask.c, in subsequent patches that will add a nodemask_t
type as an ADT sharing implementation with cpumask_t.

[PATCH] cpumask.h reorg

From: Paul Jackson <pj@sgi.com>

Push the cpumask implementation from linux/cpumask.h into asm/cpumask.h, so
that ia64 can do special things without breaking sparc64.

1) Each arch has its own include/asm-<arch>/cpumask.h file

2) That arch-specific header file can include <asm-generic/cpumask.h>,
   if it wants to make use of the generic cpumask implementation.

3) Using code should continue to include linux/cpumask.h, which
   in turn includes asm/cpumask.h.  Some common implementation
   independent cpumask related items, such as the cpu_online_map,
   are declared directly in linux/cpumask.h.

[PATCH] Add lib/parser.c kernel-doc

From: Will Dyson <will_dyson@pobox.com>

Add documentation and comments to lib/parser.c and include/linux/parser.h

[PATCH] IDE capability elevation fix

From: Alan Cox <alan@redhat.com>

Capability elevation bug in 2.6.0 IDE. Long fixed in 2.4.x, trivial to cure

[PATCH] IDE MMIO fix

From: Alan Cox <alan@redhat.com>

IDE core code had the mmio==2 (ioremap) mode supported but two small changes
had been missed for ide-dma.c.  Without this fix mmio IDE controllers bomb if
you have plenty of memory as it uses request_mem_region on an ioremap return.

[PATCH] Can't disable IDE DMA

From: Peter Chubb <peterc@gelato.unsw.edu.au>

If you try to disable IDE DMA from Kconfig, you'll end up with an undefined
symbol, ide_hwif_setup_dma().

The attached rather ugly patch fixes the problem by defining a dummy
function.

[PATCH] PIIX5 Doesn't work on IA64

From: Peter Chubb <peterc@gelato.unsw.edu.au>

The PIIX5 IDE controller on I2000 IA64 boxen using the 460GX chipset will
hang on startup if an ordinary harddrive is plugged into it (it seems to
workj for the LSI120 and the CDROM drives).

This is because the 460GX chipset contains a PCI expanssion bridge that
works like the 450NX PXB, and has the same PCI ID (but a later revision).
The PIIX driver, to work around interactions between PIIX4 and the 450NX
PXB, tries to disable DMA.

Unfortunately, the way it tries to disable DMA doesn't work, and the higher
layers think that DMA is still on, and so timeout waiting for DMA, and then
hang on bootup.

A simple workaround is to tighten the check for the buggy chipset, as in
the attached patch.  However, someone with more time (and who actually
*understands* the IDE subsystem) needs to fix the real bug as well.

[PATCH] ide-tape update

From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
      Stuart Hayes <stuart_hayes@dell.com>

- Check drive's write protect bit, try to return appropriate
  errors when attempting to write a write-protected tape.

- Moved "idetape_read_position" call in idetape_chrdev_open
  after the "wait_ready" call.

- Added IDETAPE_MEDIUM_PRESENT flag so driver would know
  not to rewind tape after ejecting it.

- Fixed bug with ide_abort_pipeline (it was deleting stages
  from tape->next_stage to end, instead of from
  new_last_stage->next (tape->next_stage was set to NULL
  by idetape_discard_read_pipeline before calling!).

- Made improvements to idetape_wait_ready.

- Added a few comments here and there.

- Made MTOFFL unlock tape drive door before attempting to eject.

- Added fixes to get Seagate STT3401A Travan working:
  Handle drives that don't support 0-length reads/writes increased timeout
  (retension takes ~10 minutes before irq is returned).
  Fixed request mode page packet command byte 3.

Also remove code depending on NO_LONGER_REQUIRED to match 2.4.x (me).

[PATCH] Minor bug fixes to the compat layer

From: Arun Sharma <arun.sharma@intel.com>

- Several instances where we were using pid_t instead of uid_t

- If the caller passed a NULL `oldact' pointer into sys_sigprocmask then
  don't try to write the old sigmask there.

[PATCH] watchdog write() return value fixes

From: gleb@nbase.co.il (Gleb Natapov)

There is inconsistency in fops->write() implementation in different
watchdog drivers.  Some of them return number of bytes written while others
return 1.

I think the correct implementation should always return number of bytes
written (we examine all the buffer after all) otherwise "echo V >
/dev/watchdog" doesn't work as expected (it doesn't stop watchdog).

[PATCH] missing padding in cpio_mkfile in usr/gen_init_cpio.c

From: Olaf Hering <olh@suse.de>

We need to update `offset' here so that the subsequent push_pad() (which
uses `offset') will do the right thing.

[PATCH] document elevator= parameter

From: Valdis.Kletnieks@vt.edu

Nick wrote a nice as-iosched.txt file, but apparently nobody updated the
kernel-parameters.txt file...

[PATCH] support centrino 1GHz

From: Jeremy Fitzhardinge <jeremy@goop.org>

I've been getting quite a lot of people mailing me about this CPU.  It
seems Toshiba has released a machine with it.  It would be nice if this
patch gets into a kernel soonish.  It's very low-impact.

[PATCH] Intel 440gx PCI IDs

- Add missing PCI ID

- Forward-port IRQ routing workaround from 2.4.

[PATCH] seq_file version of /proc/interrupts

From: corbet@lwn.net (Jonathan Corbet)

This converts all architectures' /proc/interrupts implementation over to
seq_file.  We need this for SMP machines with ridiculous numbers of CPUs and
if you convert one arch, you have to convert them all...

[PATCH] eicon/ and hardware/eicon/ drivers using the same symbols

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

The legacy eicon driver in drivers/isdn/eicon is the old one and will be
removed as soon as all features went to the new driver.  Anyway this old
driver was never meant to be non-module.

[PATCH] fix SOUND_CMPCI Configure help entry

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

the issue below is only a minor documentation fix, but it has confused
me when configuring a kernel for such a card.

[PATCH] find_busiest_queue() commentary fix

From: Ingo Molnar <mingo@elte.hu>

Clarify a comment in the CPU scheduler.

[PATCH] use alloc_percpu in percpu_counters

From: Martin Hicks <mort@wildopensource.com>

Once NR_CPUS exceeds about 300 ext2 and ext3 will not compile, because the
percpu counters in the superblocks are so huge that they cannot be kmalloced.

Fix this by converting the percpu_counter mechanism to use alloc_percpu()
rather than an NR_CPUS-sized array.

[PATCH] lockless semop

From: Manfred Spraul <manfred@colorfullife.com>

attached is the lockless semop patch. I did another test run with
idle=poll on an pentium III, and it remained unchanged: 99.9% direct
fast path, 0.1% race with wakeup against writing the final result code:

http://khack.osdl.org/stp/282936/environment/proc/slabinfo

That means there is no immediate need to add the two-stage
implementation to finish_wait.

It reduces the spinlock operations on the semaphore array spinlock by 1/3.

[PATCH] Fix writev atomicity on pipe/fifo

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Current writev() of pipe/fifo can be interleaved with data from other
processes doing writes even when the requests size is <= PIPE_BUF.  These
writes should in fact be atomic.

The readv() side is also supported for same behavior with read().  And it
is faster.

readv/writev version of bw_pipe in LMbench

2.6.0-test9-bk12
hirofumi@devron (i686-pc-linux-gnu)[1010]$ ./bw_pipe -m 4096 -M 5
Pipe bandwidth: 45.53 MB/sec
hirofumi@devron (i686-pc-linux-gnu)[1009]$ ./bw_pipe -m 1024 -M 5
Pipe bandwidth: 20.08 MB/sec

2.6.0-test9-bk12 + patch
hirofumi@devron (i686-pc-linux-gnu)[1001]$ ./bw_pipe -m 4096 -M 5
Pipe bandwidth: 65.98 MB/sec
hirofumi@devron (i686-pc-linux-gnu)[1002]$ ./bw_pipe -m 1024 -M 5
Pipe bandwidth: 32.19 MB/sec

[PATCH] optimize ia32 memmove

From: Manfred Spraul <manfred@colorfullife.com>

The memmove implementation of i386 is not optimized: it uses movsb, which is
far slower than movsd.  The optimization is trivial: if dest is less than
source, then call memcpy().  markw tried it on a 4xXeon with dbt2, it saved
around 300 million cpu ticks in cache_flusharray():

oprofile, GLOBAL_POWER_EVENTS, count 100k
Before:
c0144ed1 <cache_flusharray>: /* cache_flusharray total:  21823  0.0165 */
     6 4.5e-06 :c0144f8e:       cmp    %esi,%ebx
    11 8.3e-06 :c0144f90:       jae    c0144f9e <cache_flusharray+0xcd>
     3 2.3e-06 :c0144f92:       mov    %ebx,%edi
  7305  0.0055 :c0144f94:       repz movsb %ds:(%esi),%es:(%edi)
   201 1.5e-04 :c0144f96:       add    $0x10,%esp

After:
c0144f1d <cache_flusharray>: /* cache_flusharray total:  17959  0.0136 */
  1270 9.6e-04 :c0144f1d:       push   %ebp
[snip]
     6 4.6e-06 :c0144fdc:       cmp    %esi,%ebx
    13 9.9e-06 :c0144fde:       jae    c0145000 <cache_flusharray+0xe3>
     2 1.5e-06 :c0144fe0:       mov    %edx,%eax
     1 7.6e-07 :c0144fe2:       mov    %ebx,%edi
    11 8.4e-06 :c0144fe4:       shr    $0x2,%eax
     1 7.6e-07 :c0144fe7:       mov    %eax,%ecx
  4129  0.0031 :c0144fe9:       repz movsl %ds:(%esi),%es:(%edi)
   261 2.0e-04 :c0144feb:       test   $0x2,%dl
    27 2.1e-05 :c0144fee:       je     c0144ff2 <cache_flusharray+0xd5>
               :c0144ff0:       movsw  %ds:(%esi),%es:(%edi)
    95 7.2e-05 :c0144ff2:       test   $0x1,%dl
    96 7.3e-05 :c0144ff5:       je     c0144ff8 <cache_flusharray+0xdb>
               :c0144ff7:       movsb  %ds:(%esi),%es:(%edi)
   121 9.2e-05 :c0144ff8:       add    $0x1c,%esp

[PATCH] Use NODES_SHIFT to calculate ZONE_SHIFT

From: jbarnes@sgi.com (Jesse Barnes)

Now that we have a proper NODES_SHIFT value, we need to use it to define
ZONE_SHIFT otherwise we'll spill over 8 bits if we have more than 85 nodes.

[PATCH] Fix for more than 256 CPUs

From: Paul Jackson <pj@sgi.com>

The patch is needed to build NR_CPUS > 256.

Without this fix, you get compile errors:
    include/linux/cpumask.h: In function `next_online_cpu':
    include/linux/cpumask.h:56: structure has no member named `val'

[PATCH] ia32 WP test cleanup

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

Make the test unconditional - we can always run it now we have fixmap
support.

[PATCH] Restore /proc/pid/maps formatting

The seq_file conversion of /proc/pid/maps caused altered behaviour with
respect to 2.4.22.  Before the conversion, spaces and tabs in filenames were
displayed verbatim.  After the conversion they are escaped as \040, etc.

Also, if the mmapped file has been unlinked the output appears as

40017000-40018000 rw-p 00000000 03:02 1425800    /home/akpm/foo\040(deleted)

instead of

40017000-40018000 rw-p 00000000 03:02 1425800    /home/akpm/foo (deleted)

This could break applications which parse /proc/pid/maps (one person has
reported this).

The patch restores the 2.4.20 behaviour.

[PATCH] Get modpost to work properly with vmlinux in a different directory

From: "Bryan O'Sullivan" <bos@pathscale.com>

The current version of modpost breaks if invoked from outside the build
tree.  This patch fixes that, and simplifies the code a bit while it's at
it.

[PATCH] Be verbose about the ia32 time source

From: john stultz <johnstul@us.ibm.com>

The patch arranges for each timesource type to have a name, and uses that to
tell the user which timesource is in use at bootup time.

[PATCH] vmscan: reset refill_counter after refilling the inactive list

zone->refill_counter is only there to provide decent levels of work batching:
don't call refill_inactive_zone() just for a couple of pages.

But the logic in there allows it to build up to huge values and it can
overflow (go negative) which will disable refilling altogether until it wraps
positive again.

Just reset it to zero whenever we decide to do some refilling.