From: Sam Ravnborg <sam@ravnborg.org>

From: Herbert Xu <herbert@gondor.apana.org.au>

It seems that the %docs targets only needs scripts_basic.  The following
patch does just that.  This removes its dependency on the existence of a
.config file.

From: Arjan van de Ven <arjanv@redhat.com>

fb_copy_cmap() takes an argument about wether to do memcpy, copy_from_user or
copy_to_user.  0 is memcpy, 2 is copy_to_user.  In the ioctl you want
copy_to_user for copying the colormap to userspace.

From: Arjan van de Ven <arjanv@redhat.com>

Patch below fixes a thinko in the frame buffer drivers; the code does

cursor.image.data = kmalloc(size, GFP_KERNEL);
....
cursor.mask = kmalloc(size, GFP_KERNEL);
....
                if (copy_from_user(&cursor.image.data, sprite->image.data, size) ||
                    copy_from_user(cursor.mask, sprite->mask, size)) {
....

where it's clear that the & in the first copy_from_user is utterly bogus
since the destination is the content of the newly allocated buffer, and not
the pointer to it as the code does.

oopses have been reported in do_acct_process(), with premption enabled, when
threaded applications are exitting.

It appears that we're racing with another thread which is nulling out
current->tty.  I think this race is still there after we moved current->tty
into current->signal->tty, so let's take the needed lock.

drivers/char/tpqic02.c: In function `rdstatus':
drivers/char/tpqic02.c:700: warning: int format, different type arg (arg 2)
drivers/char/tpqic02.c:700: warning: int format, different type arg (arg 2)

drivers/char/applicom.c: In function `ac_write':
drivers/char/applicom.c:363: warning: int format, different type arg (arg 2)
drivers/char/applicom.c:363: warning: int format, different type arg (arg 3)
drivers/char/applicom.c:363: warning: int format, different type arg (arg 2)
drivers/char/applicom.c:363: warning: int format, different type arg (arg 3)
drivers/char/applicom.c:523:2: warning: #warning "Je suis stupide. DW. - copy*user in cli"
drivers/char/applicom.c: In function `ac_read':
drivers/char/applicom.c:546: warning: int format, different type arg (arg 2)
drivers/char/applicom.c:546: warning: int format, different type arg (arg 3)
drivers/char/applicom.c:546: warning: int format, different type arg (arg 2)
drivers/char/applicom.c:546: warning: int format, different type arg (arg 3)

security/selinux/ss/policydb.c:1160: warning: signed size_t format, different type arg (arg 3)
security/selinux/ss/policydb.c:1160: warning: signed size_t format, different type arg (arg 3)

drivers/i2c/i2c-dev.c: In function `i2cdev_read':
drivers/i2c/i2c-dev.c:140: warning: int format, different type arg (arg 3)
drivers/i2c/i2c-dev.c: In function `i2cdev_write':
drivers/i2c/i2c-dev.c:168: warning: int format, different type arg (arg 3)

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

clear_bit(n, addr) clears the nth bit.
test_and_clear_bit(n, addr) clears the nth bit.
cpu_clear(n, cpumask) clears the nth bit (vs. cpus_clear()).
bitmap_clear(bitmap, n) clears out all the bits up to n.

Moreover, there's a CLEAR_BITMAP() in linux/types.h which bitmap_clear() is
a wrapper for.

Rename bitmap_clear to bitmap_zero, which is harder to confuse (yes, it bit
me), and make everyone use it.

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

Sam Ravnborg found these.

1) have_vmlinux is a global, and should not be reset every time.

2) We pretend every module needs cleanup_module so it gets versioned,
   but that isn't defined for CONFIG_MODULE_UNLOAD=n.

3) The visible effect of this is that modpost will start complaning about
   undefined symbols - previously this happened only when the module was
   isntalled.

From: <john.l.byrne@hp.com>

In do_fork(), if an error occurs after the mm_struct for the child has been
allocated, it is never freed.  The exit_mm() meant to free it increments
the mm_count and this count is never decremented.  (For a running process
that is exitting, schedule() takes care this; however, the child process
being cleaned up is not running.) In the CLONE_VM case, the parent's
mm_struct will get an extra mm_count and so it will never be freed.

This patch should fix both the CLONE_VM and the not CLONE_VM case; the test
of p->active_mm prevents a panic in the case that a kernel-thread is being
cloned.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

drivers/video/console/mdacon.c:599: warning: initialization from incompatible pointer type

From: "Ronald S. Bultje" <R.S.Bultje@students.uu.nl>

Attached patch fixes a potential integer overflow in zoran_procs.c (part of
the zr36067 driver).  Bug was detected by Ken Ashcraft with the Stanford
checker.

From: <achurch@achurch.org> (Andrew Church)

The following patch fixes a bug in the processing of the sb= (alternate
superblock) mount option for ext3: when changing the device block size, the
given superblock is ignored and the code reverts to using block 1.

From: <achurch@achurch.org> (Andrew Church)

The following patch fixes a bug in the processing of the sb= (alternate
superblock) mount option for ext2: when changing the device block size, the
given superblock is ignored and the code reverts to using block 1.

From: Paul Jackson <pj@sgi.com>

I've read over the code in each case, built and ran a test case for i386 in
particular, and studied the other uses and definitions of
test_and_change_bit().  Everything I see recommends this change.

- Fix test_and_change_bit() comment: returns old value, not new one.

From: Max Asbock <masbock@us.ibm.com>

This patch makes serial line registration in the ibmasm service processor
driver depend on CONFIG_SERIAL_8250.  Previously the driver wouldn't
compile when serial driver support wasn't enabled.

From: Evan Felix <evan.felix@pnl.gov>

Here is a patch that fixes a major issue in the raid5/6 code.  It seems
that the code:

logical_sector = bi->bi_sector & ~(STRIPE_SECTORS-1);
(sector_t)     = (sector_t)    & (constant)

that the right side of the & does not get extended correctly when the
constant is promoted to the sector_t type.  I have CONFIG_LBD turned on so
sector_t should be 64bits wide.  This fails to properly mask the value of
4294967296 (2TB/512) to 4294967296.  in my case it was coming out 0.  this
cause the loop following this code to read from 0 to 4294967296 blocks so
it could write one character.

As you might imagine this makes a format of a 3.5TB filesystem take a very
long time.

From: Tony Breeds <tony@bakeyournoodle.com>

From: Tony Breeds <tony@bakeyournoodle.com>

From: Tony Breeds <tony@bakeyournoodle.com>

From: Tony Breeds <tony@bakeyournoodle.com>

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

gen_rtc.c doesn't work on ia64 (we don't have asm/rtc.h, for starters), so
don't offer it there.

From: Herbert Xu <herbert@gondor.apana.org.au>

This patch makes this file includes linux/init.h since it uses the __init
tag.

From: Martin Hicks <mort@bork.org>

I just bought an ASUS TV FM capture card, based on the saa7134 chip.  It only
had one input specified, coax.  This patch adds the Composite and S-Video
inputs.  It seems to work correctly for me.

From: Herbert Xu <herbert@gondor.apana.org.au>

The previous fix causes a syntax error when building:

Working on: /home/gondolin/herbert/src/debian/work/kernel/build/2.6/kernel-source-2.6.5-2.6.5/Documentation/DocBook/parportbook.sgml
jade:/home/gondolin/herbert/src/debian/work/kernel/build/2.6/kernel-source-2.6.5-2.6.5/Documentation/DocBook/parportbook.sgml:4059:2:E: invalid comment declaration: found character "!" outside comment but inside comment declaration
jade:/home/gondolin/herbert/src/debian/work/kernel/build/2.6/kernel-source-2.6.5-2.6.5/Documentation/DocBook/parportbook.sgml:4058:0: comment declaration started here
jade:/home/gondolin/herbert/src/debian/work/kernel/build/2.6/kernel-source-2.6.5-2.6.5/Documentation/DocBook/parportbook.sgml:4059:4:E: character data is not allowed here

This patch removes the offending line completely since that file is probably
not coming back anyway.

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

I/O port numbers can be larger than 8-bit on many platforms (this caused a
warning when {out,in}b() cast reg to a pointer on platforms with memory
mapped I/O)

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

Variable error is not initialized, but printed if tty_unregister_driver()
fails.

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

DVB_TWINHAN_DST depends on DVB_BT8XX (dependency is explicitly mentioned in
help text, but not enforced)

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

PCI multi-IO card support depends on PCI

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

Recent serial changes moved some code, causing unused variable warnings.

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

jiffies must be unsigned long

From: Martin Schwidefsky <schwidefsky@de.ibm.com>

The patch avoids the instantiation of pagetables for not-present pages in
get_user_pages().  Without this, the coredump code can cause total memory
exhaustion in pagetables.  Consider a store to current stack - 1TB.  The
stack vma is extended to include this address because of VM_GROWSDOWN.  If
such a process dies (which is likely for a defunc process) then the elf core
dumper will cause the system to hang because of too many page tables.

We especially recognise this situation and simply return a ref to the zero
page.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Michael Still <mikal@stillhq.com>

Correct kernel-doc comment with incorrect parameters documented

From: Pavel Machek <pavel@suse.cz>

If you stop process with ^Z, then suspend, process is awakened.  Thats a
bug.  Solution is to simply leave already stopped processes alone.  Plus we
no longer use TASK_STOPPED for processes in refrigerator.  Userland might
see us and get confused.

From: Pavel Machek <pavel@ucw.cz>

It makes swsusp behave correctly w.r.t.  discontingmem, and adds highmem
handling.

From: Pavel Machek <pavel@ucw.cz>

Bill Irwin did some work on this.  It makes swsusp behave correctly w.r.t. 
discontingmem, and adds highmem handling (very simple-minded, but should work
ok with 1GB).  It now should behave correctly w.r.t.  more than one swap
device, and fixes double restoring of console.

From: Rene Herman <rene.herman@keyaccess.nl>

This patch tries to improve the i386/mach-default probe_roms().  This also
c99ifies the data, adds an IORESOURCE_IO flag for the I/O port resources,
an IORESOURCE_MEM flag for the VRAM resource, IORESOURCE_READONLY |
IORESOURCE_MEM for the ROM resources and adds two additional "adapter ROM
slots" (for a total of 6) since it now also scans the 0xe0000 segment.

From: Rene Herman <rene.herman@keyaccess.nl>

The i386 probe_roms() function has a fair number of problems currently:

- When you actually have an adapter ROM in the machine, your video ROM
  disappears.  This is due to the pc9800 subarch merge that split it up in
  probe_video_rom(int roms) and probe_extension_roms(int roms), but expects a
  "roms++" in probe_video_roms() to have an effect outside of that function.

- The majority of VGA adapters these days host a ROM larger then 32K, yet
  the current code hardcodes a 32K ROM.  The VGA BIOS "length" byte is
  normally valid (it in fact needs to be for a regular mainboard BIOS to
  accept it) and I've verified on a few dozen very new to very old VGAs that
  it is.  However, assuming someone actually did not check for the length and
  checksum there for a reason, the safe thing to do here is accept the length
  byte when we also get a valid checksum.

- The current code scans 0xc0000 to 0xdffff for a video ROM while the
  standard PC thing to do (that which the BIOS does) is only scan for a video
  ROM starting between 0xc0000 and 0xc7fff.  This means that on a headless-
  (or BIOS-less monochrome adapter-) box, the first adapter ROM found
  triggers the registration of a 32K "Video ROM" at hardcoded address
  0xc0000, even when _nothing_ is present between 0xc0000 and 0xc7fff.

- The current adapter ROM scan stops at 0xdffff, whether or not an
  extension ROM is present at 0xe0000.  The PC thing to do is scan 0xc8000
  upto 0xdffff if an extension ROM is present, and upto 0xeffff when it's not
  (it's not/hardly ever).

- Adapter ROMs are called "Extension ROM", but the latter term is really
  better reserved for a motherboard extension ROM.

- Currently, the code happily starts scanning through a ROM it just
  registered looking for the next one (just does += 2048, even when that's
  inside the previous ROM) which is at least silly.

Unfortunately, this code is "subarched" between mach-default and
mach-pc9800, meaning the patch got a bit involved. Currently all this
code, and gobs of data, is defined (not just declared) in the header:

   include/asm-i386/mach-{default,pc9800}/mach_resources.h

which isn't nice. That .h really wants to be a .c. The first patch, in
the next message, does not change any code but only undoes the
probe_video_rom / probe_extension_roms split and moves the code to a new
file

   arch/i386/mach-{default,pc9800}/std_resources.c

with a header

   include/asm-i386/std_resources.h

for the prototypes only. The second patch overhauls the code itself for
mach-default. Please see comments on top of that patch for (yet more)
comments. It's tested on various machines, with and without adapter ROMs.

I haven't touched pc9800. Nothing should have changed though. The pc9800
author, as given in the code, is CCed.

Also, x86-64 inherits the probe_roms() code from 2.4, and while it
doesn't have the subarch specific problems, it has all others. I'll
convert it to if this i386 version is deemed desirable.



This patch doesn't change any code, just moves stuff from the
"mach_resources.h" header to a "std_resources.c" subarch specific file, and
introduces a "std_resources.h" header for the prototypes.

Almost everywhere where JBD removes a buffer from the transaction lists the
caller then nulls out jh->b_transaction.  Sometimes, the caller does that
without holding the locks which are defined to protect b_transaction.  This
makes me queazy.

So change things so that __journal_unfile_buffer() nulls out b_transaction
inside both j_list_lock and jbd_lock_bh_state().

It cleans things up a bit, too.