From: "Justin T. Gibbs" <gibbs@scsiguy.com>

From: Willem Riede <wrlk@riede.org>

Brings 2.6.x version of osst up to par with the 2.4.y version.
Except for the /proc changes
Tested against released 2.6.0 kernel.

Changes from what's in the kernel tree today:

- Fixes bug that files shorter than one 32K frame don't get written.
- Fix a memory alloc/free mismatch that could have made your kernel unstable after rmmod osst.
- Fix a number of tape (re)positioning bugs around filemarks that affected Amanda, Arkeia and
  Storix backup software.
- Rationalize module parameters.
- Fix time-out skipping to EOD
- Write FM+EOD+Header-update when file write terminated by ioctl
- Follow standard Unix behavior for read at EOD (return zero bytes read twice then error)
- Implement SETBLK ioctl (allowed before first write only)

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

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

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

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

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.

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

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

From: Joe Thornber <thornber@sistina.com>

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

From: Joe Thornber <thornber@sistina.com>

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

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.

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.

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]

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.

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.

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.

From: Alan Cox <alan@redhat.com>

Type errors, just fixes a warning

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

From: jbarnes@sgi.com (Jesse Barnes)

Just a quick patch to fix MAINTAINERS for sn2.

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).

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).

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."  ;-)

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.

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.

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.

From: Tonnerre Anklin <thunder@keepsake.ch>

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

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().

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.

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.

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.

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

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.

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.

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.