into hostme.bitkeeper.com:/repos/c/cifs/linux-2.5cifs

We cannot always rely on ->biotail remaining untouched. Currently we
leak all the pinned user pages when doing cdda ripping at least, so I
see no way around keeping the bio pointer seperate and passing it back
in for unmap. Alternatively, we could invent a struct blk_map_data and
put it on the stack for passing to both map and unmap.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

An unintentional sign extention caused non-ascii characters to be
stored incorrectly, leading to inaccessible files.  Changing a
declaration to unsigned char fixes the problem.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into smfhome.smfsambadom:/suse/home/stevef/bk/linux-2.5cifs

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

From: Sam Ravnborg <sam@ravnborg.org>

The external module support recently introduced caused a number of problems:
- To build an external module the Module.symvers file was needed
- To create the Module.symvers file a module was required
- If Module.symvers was missing kbuild boiled out with an error
- If vmlinux was missing also the stage 2 of module build failed (make -k)
- It was not documented what was needed to actually bauild a module

The following patch addresses this by adding the following functionality:
- Always generate the Module.symvers file
- Ignore a missing Module.symvers file
- Add a new target modules_prepare, it prepares the kernel for building
  external modules, and is also usefull with O=
- And it adds some more comments to Makefile.modpost, so others may follow
  it with some luck
- .modpost.cmd is no longer generated

This should close all reports on issues with respect to building external
modules with current kernel - which has been identified as kernel problems.

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

kernel-parameters.txt: add info on how to specify loadable module
parameters vs.  built-in module parameters

From: Stephen Smalley <sds@epoch.ncsc.mil>

Looking again at the SELinux ptrace check, I believe that there is an
unrelated race due to the fact that the parent link is only updated after
releasing the task lock in ptrace_attach (and this is necessary as task lock
doesn't nest with write lock of tasklist_lock).

The patch below changes SELinux to save the tracing process' SID upon a
successful selinux_ptrace hook call and then use that SID in the ptrace check
in apply_creds in order to avoid such races.  This allows us to preserve the
fine-grained process-to-process ptrace check upon exec (vs.  the global
CAP_SYS_PTRACE privilege => PT_PTRACE_CAP flag used by the capability module)
while still avoiding races.

From: Nathan Lynch <nathanl@austin.ibm.com>

This seems to have slipped in during a manual merge at some point.

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

A kernel janitor recently got confused by the advice in SubmittingPatches
and was sending patches with the wrong strip level, i think just about
everyone would prefer standard patches.  Also mention various patch
management scripts for batching up large deltas.

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

This patch sets the module license for mcheck/non-fatal.c.  The module
doesn't work at all without this as one of the symbols it needs is only
exported as GPL.

From: Christoph Hellwig <hch@lst.de>

The partportbook is licensed under the GFDL and Linus agreed to remove
all GFDL licensed files in
http://www.ussg.iu.edu/hypermail/linux/kernel/0306.1/1968.html.

I pinged the author the first time on the 2nd of april but still didn't get
a reply, then send a patch to Linus to remove it last week but linus
ignored it.  Here's the patch again:

From: Christoph Hellwig <hch@lst.de>

this file has been broken for ages, but it seems few !CONFIG_MMU users use
mainline at all.

From: <a.othieno@bluewin.ch> (Arthur Othieno)

Duplicate definition of dma_unmap_single() should actually be
dma_unmap_page().

(acked by Tom Rini)

Both ->writepage() and ->writepages() should return 0 or a negative error
code.  It shouldn't return the number of bytes which were written.

From: Trond Myklebust <trond.myklebust@fys.uio.no>

   Redirty the page if all of the modified parts of the page weren't
   written out.

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

These are EXPORTed SYMBOLs; 'inline' was removed from them in ll_rw_blk.c
on 2002-11-25.

From: Alan Stern <stern@rowland.harvard.edu>

This patch is needed to work around gcc-2.96's limited ability to cope with
long long intermediate expression types.  I don't know why the code
compiled okay earlier and failed now.

From: Matt Porter <mporter@kernel.crashing.org>

A copyright change to properly show the lineage of this file.

From: Pavel Machek <pavel@ucw.cz>

Stefan has pretty useful tips for getting S3 to work on radeon notebooks.
This brings whole new class of systems to be usable for S3.

From: Armin Schindler <armin@melware.de>

This patch removes the function to call a usermode helper if the hardware
and its firmware has a problem.  This feature is already implemented in the
user utility and the driver does not need to care about it.

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

mm/hugetlb.c is putting the destructor in head->lru.prev not head[1].mapping;
fix below along with nuking huge_page_release(), which simply duplicates
put_page().

By requiring that compound pages implement destructors we can drop some code
from put_page().

->writepage() is supposed to return zero or a negative error code.  Returning
the number of bytes written will confuse the VFS.

We have interesting deadlocks when slab decides to use order-1 allocations for
ext3_inode_cache.  This is because ext3_alloc_inode() needs to perform a
GFP_NOFS 1-order allocation.

Sometimes the 1-order allocation needs to free a huge number of pages (tens of
megabytes) before a 1-order grouping becomes available.  But the GFP_NOFS
allocator cannot free dcache (and hence icache) due to the deadlock problems
identified in shrink_dcache_memory().

So change slab so that it will force 0-order allocations for shrinkable VFS
objects.  We can handle those OK.

From: Marek Szuba <scriptkiddie@wp.pl>

Use the configured default NLS rather than hardwire it.

From: Matt Mackall <mpm@selenic.com>

This function doesn't correctly accumulate -EIO for its caller.

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

This patch add a system control that allows to switch off the jiffies timer
interrupts while a cpu sleeps in idle.  This is useful for a system running
with virtual cpus under z/VM.

From: Matt Domsch <Matt_Domsch@dell.com>

I moved the home of the efibootmgr utility from domsch.com to
linux.dell.com.  Note the move in drivers/firmware/Kconfig, also note
version 0.5.0-test3 or above is necessary.

From: Matt Domsch <Matt_Domsch@dell.com>

Patch below fixes three small bugs in efivars.c as posted by Matt Tolentino
last week and included in the latest -mm.  Aside from this small patch, I'm
quite pleased with Matt T's work, thanks!

- dummy() used for reading write-only sysfs files should return -ENODEV to
  indicate failure, not 0.

- efivar_create() should return the number of bytes written on success, not
  zero.

- efivar_delete() should return the number of bytes written on success, not
  zero.

From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>

Third efivars driver update patch that removes x86 references to the /proc
version of the driver.

From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>

Second efivars driver update patch that adds efivars into the drivers/firmware
directory.

From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>

I broke up the efivars driver update patch I had sent out quite a while ago
into several smaller patches.  This includes several fixes and suggestions
that were pointed out.  The patches are broken down as follows:

1 - remove all traces of efivars from arch/ia64/
2 - add new sysfs based efivars driver into
    drivers/firmware with accompanying Kconfig/Makefile
    changes to make it fully functional for ia64 again.
3 - cleans up x86 references to the /proc version of
    the efivars driver.

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

M68k bitops updates (from Roman Zippel):
  - Optimize find_{first,next}_zero_bit()
  - Add missing implementations of find_{first,next}_bit()